Double click any screen or component to rename it inline!

A couple of weeks ago we announced Double Click to Edit a text component in the builder. We wanted you to stay in the flow and focus on your content. For the same reasons, we are releasing Double Click to Rename today. If you want to change the name of a screen or a component, just double click on it. No need to go all the way to the configs panel anymore.

We're introducing several new components that make building your screens easier and faster. They're meant to do one thing very well (and hopefully named this way!)

These new components come with a simplified properties panel that gets rid of any advanced settings and focuses on the most important part. Check out the full documentation here.

• Row: Places your content in a horizontal row and allows you to control how they're distributed along the x-axis.
• Stack: Places all your content vertically and allows you to set how they're distributed along the y-axis. The stack is only as tall as the content inside.
• Center: Places all your content in the absolute center, no matter what width and height you set.
• Square & Circle: These work just like Center, except they're fixed to always be a perfect square or round circle.

Here's a video that will explain how to use simple components 👇

Now you can double click on text components to edit the text quickly!

When you're creating an app visually, shortcuts are essential to preserving your momentum. At Draftbit, we always look for places where we can make your building experience faster. For example, you can now double click any Text component to edit it right away.

Change the color theme of the status bar on top of your app!

You know those icons at the top of your screen (app notifications, time, battery, signal)? You can now make them match your app's style using the Default, Light, or Dark modes.

You can now preview your app directly in the builder!

You don't have to leave the builder anymore to see what your app looks like, to test it and iterate. You can now go back and forth between editing and previewing in just one click.

Adding a screen is simpler than ever!

We removed the intermediary popup that gave you a choice between adding a blank screen or one from our Example Screens gallery. We now take you directly to the gallery, from where you can still add a blank screen if you'd like. A simple change that makes adding screens easier and faster.

The top bar of the builder is now more straightforward!

We made the actions you care about the most more obvious to find and use. Whether it's adding a new component, previewing your app, or exporting code, all those options are now clearly labeled and always accessible at the top of the builder.

You can now see all your screens at once in the builder!

Your app is a collection of well-crafted screens. Nothing feels more natural than seeing all of your work in one view. With Multiple Screens, you can interact with all the screens at once, zoom in and out, and see the effect of themes on your entire app.

The Screens and Layout tabs are now one: Screens!

You can access all your screens in one place, switch between them in one click, and see all their components without having to go back and forth between tabs. It makes it so much faster and more intuitive to navigate within your app.

tl;dr:

• Our Engineering team recently endeavored to improve some of the slowest parts of building in Draftbit
• Two major parts of your experience are now significantly faster
• Other parts of building are also faster, as a result of this project

Here's what Sr. Engineers Patrick and Allen had to say:

Code generation and manipulating the component tree are two actions that are core to the experience of using Draftbit. It’s how you make Apps and see what they look like. On our server, we support code generation and manipulating the component tree with an essential duo of functions:

• Lister: resolved the list of components inside a given screen. 
• Tree Maker: called the first function, then converted the list to a tree.

For various reasons, Lister recursively queried our database from Fetch and FlatList branches. These round trips to the database were slow, frequent, and sequential. So adding components to these branches and seeing your changes reflected in Web Preview was also slow. We knew we could do better!

Tree Maker not only used the Lister (slow!), it did additional work to verify the correctness of the tree it was building (slower!).

First, we optimized the Lister operation by writing a recursive PostgreSQL function that resolves an entire tree of components in a single query, including the components that the Tree Maker would typically fetch. The new Lister completed more work 2-3x faster than the old function for screens with Fetch and FlatList, and 5-10% faster for all other operations.

Then, we optimized Tree Maker to quickly do its work in-memory with no further trips to the database. Finally, we combined Tree Maker with the Lister because they were so frequently called together.

As a result, we saw an additional 2-3x speedup in code generation for screens that contain Fetch and FlatList.

For the visual folks out there, here are example Sentry.io performance traces on our code-rebuilding query before these improvements (1.2 second total!):

And after (220ms!):

And we still clearly have room to improve!

So what did we learn? A few lessons stand out:

• First, profile your apps! We had an obvious target here due to good data (thanks Sentry.io!). You don't want to waste your time optimizing what isn't slow.
• Second, always try to reduce the number of trips to your database! Sometimes the time/complexity it adds to write a view, a function, or a few more joins pays back dividends in response speed.
• Third, question your abstractions when things are slow! We were doing a whole lot of work in our "tree builder" that, on closer inspection, could have always been offloaded into the "lister."