I remember back then in the initial states of ZOO how my mind was blown away with the vast possibilities it was offering. It didn’t take much to realize, though, that the bottleneck was the UI. For any new feature that the backend was ready for, the frontend wasn’t. Even if UIkit was a good start, it wasn’t until the rise of tools like React and Vue that the frontend development got to the maturity that was required by ZOO.
We don’t have to wait anymore, let’s keep on with Reinventing ZOO. If you didn’t have the chance to read the Part 1, please do so now.
We talked a lot about our new tools, but we didn’t talk about specific ZOO implementations. How would those look like? What benefits there are for the integrator? And for the final user?
We have chosen the default UIkit 3 theme as the base for our UI. We like it; the look is good and consistent. The same style will be loaded in the frontend, unless you are using a YOO theme, in which case will rely on that one style.
The Vue.js components are created and tested in isolation with several layers. The first layer is Vuikit; it provides the common base components. The second layer is specific ZOO components. Each Extension would implement the third layer on top of the previous ones.
Think of it like Lego pieces. Each piece works on its own but can have a different function when combined.
Each Extension UI is composed of a small Web App with its routing, state and workflow. It relies so little on external resources that the backend becomes a simple API.
We didn’t get there yet, but the same way our UI is extending Vuikit, any developer could create their UI components and use in our Web Apps. Even further, we could create a documented playground for helping with the task.
There is much more to discover and share about this new UI development approach. We aim to do so with the release of ZOOadmin next week, which during the Alpha state it will remain free for everyone.
We are so excited about what is to come, and we hope you will join us.