Just a few months ago, we open-sourced a frontend framework, react-crux. With the help of this framework any developer can write a simple frontend for manipulating entities in the system without having to write significant HTML code.
So, who is react crux for ?
React-crux is for any developer who..
- Needs to create an Admin dashboard to perform basic CRUD operations on complex entities in the system
- Wants a simple CMS frontend for managing objects in the database with complex relationships
- Does not want to give access to DB tools directly to their business counterparts but wants to provide similar functionalities
- Wants to write a functional good looking CMS in less than an hour
And why exactly is react-crux needed ?
In any business, we have a lot of entities which are not tied to a user. For an e-commerce company, these might be products, categories, sellers, offers, cities, etc. For a health startup like cure.fit it is memberships, centers, kitchens, employees, workouts, menu items, demand, doctors, tests, clinics, etc.
There is a real business need to create and modify these entities on a daily basis. There are three primary ways how startups achieve this
- Many engineers continue to handle creation and management of entities directly via DB Management Tools. This leads to four problems
- Engineers’ personal bandwidths become a bottleneck when businesses want to do things rapidly
- Each time an engineer switches projects/teams there is need for thorough KT / documentation
- Moreover, engineers get bored pretty soon because let’s face it — manipulation of entities is not something anyone wants to do on a daily basis, especially when their talent can be channelised towards more challenging projects
- The process is prone to manual errors! Any minor miss in critical fields can lead to catastrophic outcomes for the product in the real world
2. A few engineers create UIs for business teams to use. This is definitely better than the previous option but even the best engineers take some time to create these UIs and let’s agree, it’s definitely not the best use of their time.
3. And a few, deploy very complex CMS tools available in the market. These are a nightmare to maintain or make any changes to
After developing a couple of CMS tools, we quickly figured that to save development time & effort we were predominantly copy pasting code from one tool to another. Despite this it still took a day or two to develop/design/create a new UI tool. There had to be a better, less time consuming way!
Like many other solutions, this one came out of laziness — laziness of backend engineers to write front-end code.
We figured that the UI could simply be a config which could power the look and feel of the entire UI. This in hindsight seems trivial because almost all CMS tools do the following
- Provide navigation across entity types
- Show entities in a list / tabular format
- Show a summary/detailed view of any entity
- Give controls to create a new entity, modify/Delete an existing entity, do validations
- Provides search / filtering / sorting / pagination on the above mentioned table
So ideally, if you defined the entity in good detail and gave some UI preferences, a framework could build a generic UI. This framework is react-crux
The “react” in react-crux
Crux is currently implemented in react and so can only be used in UI applications written in reactjs. The concept though makes sense for any UI framework and we would love to see and code review a similar implementation for AngularJS, Vue, react-native, Android, Flutter or iOS.
Server agnostic UI platform
Since the framework relies on simple REST apis to fetch and modify data, react-crux is agnostic to what the server side stack is.
Pluggable into existing applications
React-crux finally gives you a react component that can be added into any existing codebase.
So, how much is cure.fit using it?
Almost 20 dashboards / CMS tools at cure.fit have been built using react-crux. These are used by a variety of teams including
- Cult Business and Operations Teams
- EatFit Business and Operations Teams
- Growth and Pricing Teams
- EatFit Kitchen Teams
- CultFit Master Trainers
- EatFit RnD Teams
- Product Managers
This has led to a huge boost in productivity since after writing the business logic and the API server, it only takes an hour or two to spin up a CMS as opposed to taking a couple of days. All we have to do is write the react-crux config!
Although the config and examples are hosted on external websites in a lot of detail, we can cover the basics in this blog post itself.
Taking the example of a simple employees table which stores four fields per employee
- Name — free form string
- Age — number
- Email — free form string
- Gender — Dropdown of existing values
Here is what a simple react-crux config looks like.
React-crux then converts the config to a proper UI that looks like this
And the modification UI looks like
This is a very basic example that helps illustrate what the tool is about. You can look at live examples website to look at more complex and real world examples.
Functionalities available out of the box
- Ability to create objects which have nested structures (any level of nesting is supported) or fields which are lists of nested objects
- Ability to choose values from a dropdown that is powered statically or from another table from the server
- Ability to filter objects locally on the client or on the server side
- Autocomplete fields based on a local list or a server side API
- Checkboxes, date and time pickers, color palettes.
- File and image uploads
- Ability to inject custom react components
React-crux uses react-bootstrap internally, so you can inject your own bootstrap styles and it will just pick it up. That way you can maintain your organisation’s / team’s look and feel across all the UIs.
Documentation and Examples
React-crux is already used to such an extent at cure.fit that it is now the default choice to create a new CMS. We are also simultaneously working on new features and requirements (the biggest one being responsive UI).
We are also figuring out a way of cleaning up the schema and making it standard and interoperable with DB schemas. This way we won’t be required to write duplicate schemas (one for DB and one for react-crux).
Extending the same thought, we are also working on a schema generator which will make this tool even more developer friendly.
We’d love for you to give it a shot and hear your feedback on our github page. And, what we would love even more is to review any pull requests to make this tool better.
Written by Ankit Gupta
Edited by Esha Savla