What if before you install a UI component from NPM you could play with it live, online, and see how it behaves? Well, now you can. Here is how.
Bit is a tool build to turn your components into building blocks which can be easily shared and synced in different projects.
Part of Bit’s workflow is to make your components discoverable to find and choose from. But, how do you choose the right component for the job?
Components could have thousands of stars, comments, even bug fixes, and still not fit your project. Maybe it has a rounded theme when you need squares? Maybe it doesn’t work with Promises and that’s a problem?
Personally, I think the best way to choose is through your own eyes. This is why I built an interactive playground where all the components you share with Bit are up and running in real time and can be played with on the web.
Creating an interactive version of code is made easy as Bit does most of the work for you. Basically, all you have to do is use Bit to share a React component, compile it as a UMD, add a usage example and see it live.
Rendering components on a webpage sound easy. After all, that’s the purpose of the code, right? In practice, code doesn’t run that well on its own. It gets a lot of support from frameworks, compilers, code servers and more.
To make it render like we want it to, we’re going to have to provide it with everything it needs and all the support it could get.
To make the code ready for the real world, we use a compiler based on Webpack. The compiler digests the code, and turns it into a UMD. The great thing about this format is that it works in all environments, including the browser, Node.js, and your own project’s workspace.
To inject all the dependencies required by the code, we go through a slightly awkward stage called re-bundling.
Rebundling takes the already compiled code, and compiles it again into a single file, this time with all its dependencies.
Unlike in the previous step, we now deal with an already pre-compiled standard code, which drastically reduces complexity. In the future, we aim to make all dependencies available as individual files, skipping this step entirely!
In this step, the code is matched with its appropriate Renderer, and a usage example, provided by the owner of the component.
Following the inversion of control principle, the code cannot make decisions about how it will be used. Basically, it needs something to run it.
That’s why we created the Renderer, which is tasked with running the code.
The renderer is a regular Bit component on it’s own, meaning that we could easily replace it following the Open Closed Principle.
We now have pretty much everything we need.
To maintain security, all of the code is loaded and run inside a sandboxed iframe. Private code is fetched outside the iframe in a secure fashion.
To wire up all the pieces of code we use RequireJS as our DI framework. You can play with the code in real time, using a Prism powered mini code editor.
To share your own components with a live preview and start playing with them online all you have to do is follow this simple tutorial.
Looking into the future, there are all kinds of interesting possibilities for this workflow, which I’m personally very proud of :).
Interactive preview is only the tip of the iceberg with what we could do with this technology. I’m certain that many teams could really benefit from real time code assembly: production debugging could be made much easier, error reporting and perf could be a side effect your code is not even aware of. The possibilities are limitless.
Feel free to give it a try, suggest feedback or create your own compilers.