Transformations

Highlights

Is there really a risk of that happening?

The need for apps is exploding

Only two decades ago (not a long time in enterprise scale) companies were not sure they needed a website. One decade ago companies were not sure they needed mobile apps. Today you might not be sure you need “smart speaker” apps (Alexa, Google Home), but trust me you will. And maybe blockchain too?

And when a new technology hits the scene, it does not make the old ones go away. You still have a fax machine in your office even if you don’t use it much. And you definitely have separate development teams for internal apps, website development, and mobile app development. Get ready for more unless you get ahead of the curve with Neonto.

But it is not as easy as just hiring some more developers

If only it was; first of all, Facebook, Amazon, Netflix, and Google get to pick first and trust me they are offering a sweeter deal than you are. When they get done taking almost all of the really good programmers, your company will be left to fight over what’s left along with a few thousand other big companies in the same boat as you.

And then there is the problem of customer experience

Many software platforms claim that they are “built for enterprise“, but are they really?

Let’s break down what a large enterprise IT shop really needs:

Great support

Reliable technology

Reasonable pricing

Ability to get a competitive edge

Minimal disruption to existing processes

Longevity

Ability to adapt or customize to unique standards and business process

Every company is going to claim it has the first two and being a competitor, not a customer, it is not my place to dispute that, so let start with the third item.

Reasonable pricing

Paying by the user is great from startups and early-stage companies, but for enterprise, it is the worst pricing model possible. We can say right off the bat that any company that has a per-user license fee is not really built for enterprise after all.

But there are other “gotchas”. What about companies that try to “lock-in” their customers with special runtime libraries that make it impossible to continue running apps with also continuing to pay a license fee. Is that really reasonable? Not for a large enterprise which absolutely must control its own destiny. It is not reasonable to demand that investments on the scale of enterprise applications be held hostage that way, preventing the customer from moving on if they are truly dissatisfied. So any company tries to lock you down in any way is not really reasonably priced either.

Ability to get a competitive edge

Citibank does not want to look exactly like every other bank out there, and Macy’s does not want to look like Bloomingdale’s. Large enterprise makes large investments in branding and identity, and being able to slap a logo on a template does not make the template better; it makes the brand worse. There aren’t any Fortune 500 websites based on WordPress templates.

Some platforms allow “customization” of template built apps. It will never be enough to give your designers the creative freedom they need to adhere to and enhance the brand identity in meaningful ways.

Any platform that does not allow unrestricted use of any programming language whatsoever (your designers might not be using CSS and Javascript, they are probably using LESS and CoffeeScript or TypeScript) cannot truly be said to be built for enterprise.

Minimal disruption to existing processes

Small companies can turn on a dime. A small company owner can arbitrarily decide that an entire department has to switch tools and retrain, no matter the cost in term of business disruption. Large companies do not work that way.

In an enterprise situation, the cost of disrupting tooling or business process necessarily includes multi-month (even multi-year) change management and training and transition plans. Change at that level is painful. A platform that was indeed built for enterprise would minimize disruption. It would allow the continued use of all existing toolsets and would plug into the business process as a transparent additional step.

Any platform that forces developers or designers to stop using familiar tools, or forces a new infrastructure on the operations team, or completely disrupts the deployment/delivery process definitely not built for enterprise.

Longevity

The world changes, especially the IT world. If this was not true, all enterprise programs would be written in COBOL and we know this is not the case.

Enterprise has enough problems with technology refresh as it is. A real enterprise solution would alleviate the problem by preserving application logic in a re-useable, programming language agnostic format, not aggravate it by burying business rules in a proprietary, locked-in platform. To assure longevity, a solution has to be designed from the ground up to support the real-life truth that programming languages change every decade or so.

A platform that aggravates the problem by tying up the results of priceless analysis into a language-specific solution is in no waybuilt for enterprise.

Ability to adapt or customize to unique standards and business process

To summarize the previous points: large enterprise lives in a world of its own making. It cannot, and will not, change to fit into any else’s mold.

For a few years in the Nineties, it was fashionable to try and solve every IT requirement using Commercial-Off-The-Shelf (COTS) software. This did not last long, and today all successful large companies make substantial investments in in-house software development.

Ultimately, two iron rules cannot be broken: to gain a competitive edge a company has to differentiate and cannot be the same as everyone else, so it cannot be “handcuffed” into some third party’s idea of how they think everyone should work.

A solution or platform that imposes anything at all, whether it is a programming language, tools, infrastructure, or business process is ultimately not built for enterprise.

So?

To be built for enterprise, a solution has to, therefore:

Provide great support

Be based on proven reliable technology

Be reasonably priced and not try and lock-in the customer

Provide a truly customized solution (based on common technology) to each customer

Work with all existing tools and minimally disrupt existing processes

Be language agnostic and able to evolve as programming languages and techniques evolve

Enhance an enterprise’s ability to create a unique brand idenity and experience

Neonto meets all of these criteria, and we believe that we are the only competitor that does. Make the right decision, choose Neonto.

We have such a fixed idea of what programming is, it almost impossible to imagine anything different.

In 1984 I used a computer for the first time. I tried a Macintosh, but it seemed to too simple. I intuitively felt that I wouldn’t be able to do anything interesting or complex with it. So I got an IBM PC and a copy of Lotus 1-2-3, and I was satisfied with the ridiculous complexity of figuring out interrupts, navigating the world’s most broken operating system (DOS), and coping with memory so small that it could only hold about 5 pages of text before it exploded. Now that was s serious computer!

I gave up on it and didn’t touch a computer again for a year or so, at which point computerizing my production office seemed inevitable. I researched computers, and this time bought a Macintosh Plus because it could be configured with six times more memory than a PC, and that seemed important to me. The salesman also sold me a programming language called Omnis, and I proceeded to teach myself how to program a fairly complex system for film production.

It turned out that the Macintosh’s simplicity of use did not prevent me from accomplishing complex programming. As I dug deeper into programming, learning Pascal, C and Assembly Language I came to understand that the Macintosh’s apparent simplicity was the result of incredibly sophisticated and complex (for the time) programming.

One of the hallmarks of expertise is a real expert makes things look easy. Babe Ruth and Rory McIlroy seem to be barely breaking a sweat. How many guitar players have listened to Eric Clapton’s opening bar of Hideaway and thought to themselves “That’s easy, I could do that”?

It was a mistake for me to believe that the Mac wasn’t powerful because it was easy. The fact is: it was easy because it was powerful.

Most people have a similar mental block when it comes to visual development, also called “no-code” development. We are so used to thinking of programming in terms of typing a strange language in green letters on a black screen, that it creates an unconscious bias against anything that is simpler, easier. Once again the truth is the opposite: it takes considerable skill and sophistication to create a good no-code platform, but once it is done right, it is powerful. In some ways more powerful than traditional programming on that green screen.

I can almost hear some of my readers saying “Hold up! Slow up! That can’t be right.” But let’s think about cars.

Just about 100 years ago, cars were built the way we build software today. A car could not be built without master carriage builders and master mechanics. Each car was built from start to finish as a one-of product. Parts from one car could not be just switched to another. They would have to be machined, fitted. This system of production is not scalable. To build many more cars, one would have to find many more master craftsmen, and there is not an unlimited supply of those. Also each master works in their own fashion, slightly (or very) differently than the next. There can be no standardization, no economy of scale, no consistency.

You would not expect an application development project to be successful if all of the programmers were either inexperienced or not very good programmers, you must have one or more master programmers from the start of the project until the end, and when we take a chink of code from one program and paste it into another, we have to go through it very carefully, individually fitting it into its new home. And… there is not an unlimited supply of master programmers, each master works in their own fashion, slightly (or very) differently than the next, there is no standardization, no economy of scale, no consistency.

Today, the process of building a car is very different. Designers and engineers work very hard for a few years preparing a new car model for mass production, testing designs and building the tooling for the production line. When the car goes into production, the designers and engineers move on to other projects, and the cars are assembled by robots and semi-skilled labor, workers with no design or engineering training. And it scales. Need more cars, just add a shift to the factory. Or build a new factory and hire more workers, who with no professional training are much easier to find than engineers and designers. Quality is better too. Because of standardization, quality and the consistency of that quality is astronomically higher than it was 100 years ago.

No-code platforms follow the same philosophy. Careful design and engineering produce an inventory of interchangeable parts that can be assembled into an app by workers unskilled in programming. Because the code has been written, tested, and debugged before it is used to create an app, the apps are robust, bug-free, and production-ready as soon as they are built.

How plugins work in React Studio, and what design-guided metaprogramming can do for you

In this post, we’d like to introduce you to the heart of React Studio: the design compiler. We’ll take a look at how React Studio plugins work and how Neonto’s design compiler can intelligently bring together your code and visual designs to construct React projects.

More fundamentally, this is about new abstractions for programming. The design compiler is actually an evolutionary step beyond libraries and frameworks. On a quick glance at React Studio, you might think “just another GUI builder”… But you’d be missing something essential. There is a whole level of metaprogramming capabilities in React Studio that makes it so much more!

You’ve probably seen code generators and declarative UI design tools before, but React Studio is neither. It combines features of both of those approaches into a single metaprogramming tool — an “application that writes applications” as guided by your inputs.

There are two significant practical benefits to this approach. The first is encapsulation safety. This could be compared to type safety: in a programming language with static types, the compiler can catch many kinds of errors before you even run the program. The design compiler does something similar — except for entire code fragments, not just individual variables.

The other benefit is framework independence. There are many frameworks out there that promise some kind of platform independence (“write once in language X, run anywhere!”)… But the design compiler approach takes it one level higher. You can actually retarget your app design to a different programming language and framework, just like you can compile a C++ program for a different CPU and operating system. (This is not just a theoretical possibility; at the end of this post you can find non-React examples of the Neonto design compiler in action.)

On the process level, the design compiler enables a new kind of software development workflow that we are calling Design-Accelerated Development. (That acronym is quite a “dad joke” in itself, isn’t it…?) In this post, we won’t go into details on that because focus here is on the technical aspects of the design compiler and its plugin interfaces. But we are going to tell you about our ideas for Design-Accelerated Development workflow in another series of posts soon. (Don’t miss that: follow us here on Medium)

“Peak Framework” and the limits of runtime

We wrote a separate post (link below) about the thinking that led to the design compiler approach. In brief, the software industry has reached “Peak Framework”. Buildtime tools is where the action is today. But do we have the right abstractions?

Modern build tools could be so much more than text editors and terminal commands — and that’s where React Studio comes in.

Inputs and outputs of the design compiler

A picture speaks more than a thousand words, so here’s a diagram. (Well, this picture does have quite a few words in it, so maybe it’s cheating…?)

The output is always a React project using Facebook’s create-react-apptoolchain. This is a very solid base for modern web app development: you get a prepackaged build system with everything needed both for local testing and deployment builds, and the language environment is set up to support latest best practices (e.g. new JavaScript features that make React/JSX code more concise). If your needs later diverge from Facebook’s defaults, you can “eject” the project and modify it manually.

The inputs are what feed the design compiler. These are both visual (layouts, drawings and configuration made within the React Studio GUI) as well as programmatic in the form of plugins. The plugin system provides an advanced set of “hooks” into both the design compiler and the Studio GUI.

The default installation of React Studio 1.0 includes a few plugins: two web service plugins (a.k.a. data plugins), two component plugins, and defaults for the UI framework and navigation plugins.

The default plugins are useful as starting points for your own plugin development. There are really two ways to make a plugin: 1) take your own custom code work and wrap it into a plugin, or 2) take an existing npmpackage and make it available as a plugin in React Studio. We’ll look at examples of both.

Structure of plugins, and where to find them

Camera plugin

The default plugins were installed by React Studio in the folder:

~/Library/Application Support/React Studio

The ~ symbol means your home folder. You can get into the ~/Library folder easily in Finder using a hidden shortcut: open the Go menu, press down Alt key, and the Library item appears.

Plugins are macOS bundles. This structure is commonly used on both macOS and iOS, and it’s a very practical way to package together code and resources. Bundles are really folders that just appear like single files to the Finder. To read and modify the contents of a plugin, right-click on it in Finder and choose Show Package Contents.

If you have a .plugin file, you don’t have to go to the Library folder to install it — you can do that in React Studio by using the Plugin Manager (found in the Plugins menu).

It’s possible to keep plugins in a project-specific location. This is very useful for two things: testing your plugins while developing, and managing advanced projects where you want to make sure that your project and its source plugins stay in sync. There’s even a Reload command that lets you load project-specific plugins without having to restart React Studio — highly convenient for development. You can find this in Project Map > App Settings block > Plugin settings.

Starting a new plugin

It’s easiest to start a plugin by modifying one of the default ones. First make a copy of the plugin in Finder and give it a new name.

To really rename the plugin, it’s not enough to just rename it in Finder. You must also edit Contents/Info.plist and replace the plugin name in both the “bundle name” and “bundle identifier” fields. (The bundle identifier is an internal package id that is used by the operating system; the “bundle name” is a human-readable version of your plugin’s name.)

Code and assets

The plugin’s main code is in Contents/Executables/Main.js. This contains the definitions and functions that are called by React Studio to perform tasks like creating a UI for the plugin and processing code fragments for the design compiler.

Camera plugin React code template

In Contents/Resources, you can find templates that provide React JSX code. (For plugins that just wrap an npm package, there may not be any need for a template, but more complex plugins will have something here.) Our internal practice has been to use the Mustache templating language, but this is not set in stone — it’s not a fixed feature of React Studio, but just a JavaScript dependency that gets included in each plugin via a setting in Info.plist. You’re completely free to use some other library or method for your templating needs, if you prefer.

Component plugin: Camera

This plugin is a compact example of a self-contained component plugin (i.e. all of the code is in the plugin, nothing is loaded at buildtime using the npmpackage manager).

The Main.js file is reasonably well commented, and contains the code for all the entry points called by React Studio. All of them are declared in the context of a “this” object — this represents the plugin instance (i.e. when you drag the Camera element into a canvas, an instance gets created, and the “this” object will point to that). You can also place private data in the “this” object; the convention is that such private data is prefixed with an underscore. In Camera, the only such declaration is “this._data”. (This object gets saved within the React Studio project thanks to the implementation of the persist/unpersist functions.)

The real beef of the plugin is in the exportAsReactWebComponent function. The arguments are a class name and an exporter object, which can be used to access React Studio’s design compiler state. Camera’s implementation of this function loads a template file from its Resources folder, then uses the Mustache template engine to fill out some values within the template code.

Another interesting method is writeReactWebCodeForPublishedInteractAction. This lets you write the JavaScript code for a previously declared interaction. Camera provides an action named “Shoot”, which lets the user take a picture and save the image data into a data slot within the React Studio project. (Actions can be chained in the React Studio UI, so typically the “shoot” action might be the first one in a chain where the image gets eventually sent to a server.)

Component plugin: Rating (wraps an existing npm package)

This plugin is interesting because it wraps an existing package from npm, one called react-rating.

The implementation here looks quite similar to Camera, but there is no template in the Resources folder — we don’t need one because the component code comes from the npm package.

Instead, the plugin declares its dependencies using the getReactWebPackageshook. Rather than write a component class, the plugin declares that it doesn’t need one (using this.writesCustomReactWebComponent = false), and implements a getReactWebJSXCode function. In this function, the plugin just returns an instance of the Rating component configured according to user-settable values from the React Studio UI.

Data plugin: Generic JSON

The Generic JSON plugin shares many similarities with the component plugins seen earlier. The type of plugin is different; this is declared in Info.plist using the key NeontoPluginTypeId. (The Info.plist file is a required feature of the Apple bundle format; all the keys with a “CF” prefix are defined by Apple. The only ones you typically need to edit are bundle version, name and identifier.)

Generic JSON’s Main.js has some of the same parts as the component plugins. There’s a describePlugin function, some private data, an inspector UI declaration and action methods, and rendering an icon for display (which just fetches an image from resources).

The readDataSheetFromServiceAsync function is used to load data inside React Studio. This allows your plugin to load data to be used at design-time — very useful!

For the output, there’s a writeReactWebCodeForDataSheetLoad function. As with the Camera plugin, it uses a Mustache template as the basis for the JavaScript code.

Data plugin: RSS Feed

RSS Feed is similar to Generic JSON above, but has two distinguishing features.

For the design-time preview, the data is loaded using an XML parser. The library for this is included in Resources/js/sax.js. This library file needs to be declared in the plugin’s Info.plist (key NeontoPluginDependencies), so that React Studio loads the library code into the plugin instance.

The actual exported JavaScript code has a peculiarity: it performs an AJAX-style to load the RSS feed, but it doesn’t call the server directly. Instead it proxies the request through Neonto’s “API Bridge” server. (You can see this at the start of the Resources/templates-web/DataSheetLoad.js file.) This proxying is necessary because RSS feeds can’t be directly loaded: they are typically served by plain-HTTP servers, but modern web browsers require HTTPS for all requests. Also there is a question of cross-origin requests being allowed — most servers that offer an RSS feed don’t allow AJAX loads of the feed. For these reasons, Neonto offers the API Bridge.

As part of your React Studio subscription, you have access to the API Bridge. Initially we offer Google Sheets and RSS, but new services can be added easily — let us know what you’d like to see on this front!

Plugin development questions?

We’d love to help you make your own plugins. There are a number of ways to get in touch, choose whichever is most convenient for you!

Neonto’s design compiler for other platforms

So far we have looked at examples of plugins that specifically output React web code, JSX and CSS… However Neonto’s design compiler supports other targets too!

Neonto Native Studio is an enterprise-ready product for native iOS and Android development. It uses the same design compiler core to construct truly native (“frameworkless”) projects for iOS and Android. It’s being used to produce hundreds of native apps already. If your interests are more in the native mobile space, check it out! There is a free 14-day trial available.

The default installation of Native Studio includes a Camera plugin that is very similar to the one you find in React Studio. (In fact, they could be the same plugin: you could have both the React and native implementations inside a single Camera.plugin … We didn’t do this just because we don’t want to confuse you with the implementations for non-React targets.)

If you’re looking to understand how Neonto’s design compiler can produce native code for multiple platforms from the same design inputs, the Camera plugins are a good place to start. You can then explore further with advanced APIs at the Native Studio developer site.

The software industry has reached “Peak Framework”. Buildtime is where the action is today. But do we have the right abstractions?

Do you know the “Hubbert peak”? Originally applied to oil production, it is an observation that the production of a natural resource tends to follow a bell-shaped curve. There is an initial phase of exponential growth when the easily accessible resources are discovered and exploited, but then the rate of discovery inevitably falls and a peak is reached.

Well, the software development industry has its own Hubbert-like curves. Around 2009, we had “Peak Dynamic Language”. With the rise of the web, new dynamic programming languages like Ruby and PHP had seen explosive growth. There was widespread enthusiasm surrounding the rapid development practices enabled by flexible typing and the ability to “monkey-patch” everything at runtime. This enthusiasm peaked when web applications grew larger and the runtime unpredictability of dynamic languages became more of a problem. After the peak, static languages have enjoyed a strong resurgence.

Now in 2017, we are facing “Peak Framework”. The past ten years have seen an amazing explosion of libraries and frameworks for the web platform. This trend originally got started by clever approaches to patch over painful discrepancies and incompatibilities between browsers, but soon turned towards complete application frameworks like Angular that aim to provide a runtime solution to everything that’s wrong with the web.

This approach is peaking because developers are starting to realize that there is a fundamental limit to what can be done by adding new software layers into the runtime environment. Frameworks come with two high costs. The first is technical. Each dependency adds to your application’s startup time and footprint. A typical web app developed with one of these “kitchen sink” frameworks will load several megabytes before it loads a single line of code that is actually about your app. This is bearable today (if you’re on a computer and a fast Internet connection), but the frameworks can’t grow any bigger — nobody is going to wait for a 50 MB framework to load into a browser.

The second cost is mental. Web frameworks are complex, yet there is tremendous churn. Developers had barely familiarized themselves with Angular when Google announced that Angular 2.0 would take a different approach and would not be code-compatible. How much time are web developers spending on researching and learning new frameworks versus working on their actual projects? Sometimes it seems the balance has tilted towards the former, and that’s not healthy. Carpenters don’t spend most of their time reading about drills and lathes.

That analogy brings us to another important point, namely that software development today still largely operates like a mom-and-pop woodwork shop, even inside large corporations. Someone brings you a design on a napkin (a PSD, a Sketch file, a Zeplin styleguide, whatever — it’s still a napkin!)… And then you get to work, tinkering with your manually operated tools and artisanally feeling your way while sometimes glancing at the napkin to remind you what you’re supposed to be making.

It goes without saying that this is not how most physical products get made in the real world. Hand-crafted objects are an expensive luxury. Ordinary mass-market products are made using CAD tools and rigorous industrial methods. Yet we have none of that in the software world. Every app gets built like a Swiss watch or a Hermès leather bag, but not every software developer is a master watchmaker… And so we have an industry that faces both serious quality issues and demand that greatly exceeds supply. Maybe it’s time to do something about it?

The runtime barrier

The essence of the “runtime barrier” is that adding more layers of software into the runtime environment is like adding more tools into the woodworker’s shack. There is a limit of decreasing utility to new and increasingly complex tools at that level of operation. You could give the carpenter a million-dollar 3D printer, but it won’t improve his work because his method of working can’t accommodate it.

That’s why the focus of interest in software development is switching from runtime to buildtime. It’s the same kind of transition as the one that happened after “Peak Dynamic Language”: runtime complexity has become too unpredictable, and we want to catch more errors earlier while also reducing memory footprint. In the web world, this has converged around tools like Webpack and Babel. Ten years ago, web front-ends typically did not have build chains worth mentioning. Today, a modern web app’s build setup takes hundreds of megabytes (e.g. an empty project brought up using Facebook’s “create-react-app”), and this often includes a compiler for an entire programming language (Babel’s latest JS, TypeScript, etc.)

So, buildtime is where the action is today. To continue the previous analogy, we are in the process of switching from woodwork shops to factories… There is one curious thing about these new factories, however. Their output is configured and controlled using the same kind of tools as in the previous “shop” phase: command-line tools, plain-text source code files, text editors.

Is this the right level of abstraction to control a factory? Would Foxconn be able to operate if their manufacturing processes were managed by the same tools as “Jimmy’s Wood Shop”?

Maybe the modern build tools could be different, something beyond text files and terminal commands. We could learn a few tricks from those real world factories and their tool chains. What if your software development process had the equivalent of CAD design tools and their ability to directly interface with physical manufacturing (CAM)? What if you could encapsulate custom functionality in a way that follows factory-style modular thinking (rather than the hazardous “edit any text file” approach of code shops)? What if you could replace core libraries of your app without touching every source code file, similar to how car manufacturers can swap out engines and other components for different models while still using a single cost-effective base?

The modern web is a complex platform, and innovating in build tools is really hard. So we fully realize that we’re not fully there yet, even though large parts of the vision are implemented and working today. If you are interested in the direction we’re taking, why not sign up [link] and engage in our Slack channel or private conversations! With your feedback, we can hope to build something that makes your work easier and better in the future.

By the way, we did not start from nothing with React Studio. We’ve been successfully piloting the “design compiler” build tool approach for two years with Neonto Native Studio, a product that uses the same core to construct truly native (“frameworkless”) projects for iOS and Android. It’s being used to produce hundreds of native apps already. If your interests are more in the native mobile space, check it out!

The makings of a component

According to Facebook’s official React documentation, “components let you split the UI into independent, reusable pieces, and think about each piece in isolation.”

Components are the fundamental building blocks of a React application. They can be as small as a button with two states, or as big as an entire screen full of content. They are often composed inside of each other, so it’s important that your components are as independent as possible.

If you want to learn more about how to make components in JavaScript, all the information is on Facebook’s React documentation site:

But let’s state the obvious — you’re reading this because you don’t want to be writing components directly in JavaScript code!

Indeed, as visual building blocks, React components are the perfect kind of thing to be designed graphically rather than directly in code. React Studio lets you do exactly that, and next we’ll show you how it works.

Use vector graphics

In general, you want to use vector graphics in your components rather than bitmap graphics (such as PNG images). Using vectors makes your component easily scalable to different screen sizes and pixel densities. It’s also easier to edit your component’s contents for different states when you have everything in vectors rather than fixed bitmaps.

React Studio has the essential drawing tools for vector shapes, so you can do most things directly in its interface. However, you don’t have to!

We also have a powerful import plugin for Sketch. For this tutorial, I’ll bring in some simple graphics via this route.

Here’s a simple Sketch document with just one artboard:

The component shown here is an online status indicator. We might use this component in a list to show when a particular user is online and also display some contact information information in that case.

To transfer these graphics into React Studio, look in the Plugins menu in Sketch:

In React Studio, the transferred component will look like this:

Again, this is the kind of graphics we could have easily drawn inside React Studio too, but I really wanted to show you the Sketch plugin! It works for much more complex designs too. (You can even specify things like whether elements should go in the foreground or scroll flow groups in React Studio.)

Now that we have some graphics, let’s move on to defining the component’s behavior.

Component properties

Most components are not static, but dynamic. In other words, the content of the component needs to change in response to outside commands.

Properties (also called “props”) are the React way of passing data into a component from the outside. To make efficient use of React Studio, you need to know a bit about properties and how they are passed inside the React app you’re making.

For this “online status indicator” component, there are clearly at least two properties:

– Online / offline status

– User’s contact info (shown only when online)

The online status property needs to affect three elements:

– Circle’s color

– Text content of the big label (“User online”)

– Visibility of the contact info label

Let’s see how to define these in React Studio.

We can start with the contact info because it’s straightforward: the label will simply show the value of a property named “contactInfo”.

Select the element, click on the Data tab in the inspector, and enter the property name in the “Text” field under “Take value from property”:

That’s all!

Now the property’s name appears in the top-left corner of the canvas editing area. There’s also a thin blue line that links the name of the property into the element(s) that are using it:

This makes it easy to see what properties are actually used by your component. (If you’re a designer and you will hand this component over to a programmer, he/she will appreciate this info!)

Next, we want to make this component react to the user’s online status. We could do this in the same way, using text/color properties on the graphics and text (together with some small scripts to select the text content)… But there’s an easier and more designer-friendly way.

States

React Studio has a timeline-style interface that lets you visually define different states for one component. In this case, we just need two states: online and offline.

Click on the “Add State” button above the element list. You’ll see a new state appear on the right-hand side of the list:

This interface is intentionally similar to what you might find in a video editing app.

Each element is like a “track” of video, and you can cut or extend the elements so that they fill multiple states or don’t appear in a state at all. (There are “arrow” and “blade” tools right above the element list that can be used for these editing operations.)

In this case, we could use the first state to represent “offline” and the second state “online”.

The second state is actually all ready, so we only want to edit the first state. Select the “User online” element in State 1. In the editing area, double-click on the element to edit its content, and change the text to “User offline”.

Then double-click on the green circle. This takes you into shape editing mode, where you can modify the vector graphic. Change the fill color for the circle to red:

Click “Back” to return to the element list.

Finally, click on the contact info (phone number) element in the editing area, and press Backspace to delete it because we don’t want to show this info when the user is offline.

Now you should see the following:

Our two states are now ready.

As a last step to making this component more usable in code, you could rename the elements. Click on an element name to change its name. You could name them something like this:

Creating component instances

Now that we have a component, we can use it elsewhere: in another component or a navigation screen. (To tell you the truth, screens are really just components that have special status inside React Studio so that you can make navigation more easily. So there’s no difference whether you use a component inside a screen or another component.)

Open a screen and drag the component from its Project Map block (where it says “drag from here”) into the screen’s editing area:

You’ve just created a “component instance”. You could think of the component itself as being like a blueprint: it’s not quite the thing itself, just the plans you can use to create physical instances of the thing.

In this case, the instance was created by dragging. It’s just a single instance that you can configure. (In another typical use case, component instances would be created by a List element which repeats a component as many times as there are “rows” of data. This tutorial won’t show you that, but you can look in the Elements box to find the List element.)

Select the component instance and look at the Inspector on the right-hand side. You’ll see settings that you can configure for this component:

The component wasn’t renamed yet, so it’s still called “Component 1”.

Click on the “Active component state” selection box and choose “State 2”. The component instance will now display the online state.

Congratulations, you’ve just made a real React component with properties!

Previewing the code

If you’re a programmer (or work with one), you might want to see what the React JavaScript code for this component looks like. You could export the entire project, but there’s an easier way.

Go back to the component itself (double-click on it in Project Map). Then click on “Code Glance” in the app toolbar. This opens a JavaScript editor that shows you the exact code that will be exported.

Code Glance feature in action

Component UI

Previously we saw the user interface for the component instance — just a text field for the “contactInfo” property. This was automatically generated when we added the property.

That UI is good enough for the “contactInfo” property, but for other kinds of properties we might want to have something more complex. For example, if we had a property called “backgroundColor”, we’d probably want the UI to be a color picker instead. Or, we might want to add some explaining text so that the person who uses our component later knows what these properties mean.

For these situations, you can easily override the automatic component UI and design it yourself. Select the component in the Project Map and uncheck “Auto-generate from properties”: