It’s MVC! No, it’s PAC! No, it’s… something new?!? 😲
Towards a simplified and intuitive development model we go
First things first, who are we?
We are grammatically incorrect and wise as Yoda was.
We fly high and save children from burning houses as Superman would.
Our combined powers make us as dangerous and stubborn as Einstein and as sexy as Justin Bieber.
We question, defy, and reinvent the status quo because we can. This post is the best example — a comparison of architectural models written by a designer! 😱
Why don’t we use what’s out there already?
To answer that question I need to give you quick overview of existing development models, but before you think I’m bashing any of them let me say that it’s better to follow a model than not to have one. In our work, we are exploring space for improvement, and this post explains how we went about it. So, once again, this is not a hate post! 😇
OK, let’s bring up the most common models:
- MVC — Model / View / Controller — used to be the most popular choice when I was younger and didn’t have grey hair. Let’s just say that the biggest problem with MVC and its friends (listed below) is a stateful state, meaning that model controls the view (or usually many views) and the view does what it’s told to do. It’s horrible to make changes in a stateful app because you need to make sure not to break the model accidentally. So in short, you need to understand the full model well and at all times, which is extra hard in general and mind-blowing if many people are contributing to the project.
- PAC — Presentation / Abstraction / Control
- HMVC — Hierarchical Model / View / Controller
- MVVM — Model / View / ViewModel
- MVP — Model / View / Presenter
- MVA — Model / View / Adapter
- RMR — Resource / Method / Representation
- ADR — Action / Domain / Responder
😅
Even the acronyms are confusing, so let’s not get into the details. Google them or trust me that complexity of these models is unbearable for a non-technical person like me.
We like simple things!™
Answer ☝️ to why we don’t use what’s out there.
What about React?
We all stand on the shoulders of giants. For us, React was the most significant step forward towards a simplified and intuitive way of building software.
Some people were comparing the architectural model of React to V in MVC, which stands for View, but that doesn’t say much about the differences. That comparison was a stretch either way since React apps don’t fall into any of the models listed above.
One of the core concepts of React is the encapsulation, meaning that the component is fully responsible for what is going on with it. That moved the Controller closer to the View, and global logic was abstracted into Hooks (introduced recently in React). Hooks are reusable pieces of business logic, but they could also hold parts of the state.
The state in React is local to the components, and each component could share it with its children. To me the State is sort of like the Model in MVC, 😬 , so since there are not enough acronyms in the world, I’ve made one for this occasion. Hate me all you want, but there it is:
DSVH — Distributed State / View / Hooks
Still sounds complex to a non-technical dude like me.
Our Way
We call it Views, which accidentally makes sense since it’s compiling to React — Views is a dev dependency, meaning that it’s used only during development and it’s never shipped to the client (client is a browser or mobile device, components made in Views are platform agnostic and ship without refactoring to the browser as React DOM and to iOS / Android as React Native). We call our compiler Morpher because it morphs Views blocks with state into React components.
What’s so new about it?
We designed Views architecture with a goal to make it intuitive even for non-technical people, meaning that we created it for folks like me.
Disclaimer: Looks like I know my stuff, but in fact, I don’t. And that’s what is so great about Views! I can make meaningful contributions to the state, interface, and data models without going hardcore into engineering details.
Views architecture makes state management simple.
There is no external model to define the state, and we infer data by its use from the GraphQL layer. Everything that the View needs is defined in the View or its direct wrapper called the Logic, which is a regular React component. Additionally, we are using Hooks to set the flow, format and validate data. Our Hooks are stateless, though. They are pure functions with inputs and outputs. No state.
We removed the need to manage the State as you would be in the React model, and we made it easier to reason about the flow and the data.
That’s where the simplicity comes from. ☝️
OK, so we use Views and a Graph. Let’s be fair and acronymise, 😁, the living hell out of Views model too. Here’s my take at it:
VG — View / Graph
Good, but there is one more thing! We gave our Views special abilities.
Ability 1. 💪
Views create a folder-like structure of self-contained components rendered together or separately with other Views.
In this example, Login and Signup are two Views inside of the App View. We can set the App View to render Login together with Signup or separately. If we decide to render them separately, we would need to add an action to allow users to go to Signup View. Without the action, there would be no way to switch the state of the App from Login to Signup.
This is a very easy to follow abstraction. It works in simple and complex cases. The big advantage of Views state machine is how clear it becomes to everyone on the product team, even to the designers and product owners.
Ability 2. 💪
Each View can show, capture, validate, and format data.
In this example, the Email View defines the data for the email Input. The first parameter has two choices: capture and show. We also have the flexibility of showing both, but not in the case of login. Next parameter specifies the context and the point in the GraphQL API responsible for storing the data in the right place. Data validation is an example of the globally reusable logic, and it makes sure that users input matches the expected type on the back-end, in this case, we are looking for an email. We can also require data which gives us the ability to disable actions if users don’t provide what’s needed.
Having the View to define data connection is a clean and declarative way of using data in the front-end. It also improves the level of understanding the data flow and data use. Data becomes less of an unknown that developers know about and more of a thing we all do and get. To Dan’s point here, simplicity of data modelling in Views grows the awareness naturally:
We are now working on having the Morpher to take over the query automation, so the GraphQL queries and mutations don’t have to be written manually by developers.
Ability 3. 💪
Views are composable within the interface layout and still behave like a state machine for your business logic.
In the Login example, Views that connect to data (Email and Password) and the View that creates the flow (LoginAction) are part of the interface layout together with the Title block.
This approach makes all Views composable and offers ultimate flexibility through reusable patterns.
TLDR, We reduced our model to two layers. The View controls how does it render itself in relation to other Views + it defines the interface blocks + connects data if needed. We removed the Store and re-distributed the additional logic as wrappers with each View.
Does it work?
No, this is April Fools post. Stop reading here. 🕺😂
We’ve tested the current implementation of the Morpher, state machine, and Views language in seven projects over six years of development.
I will say only two things about how well it works:
- I love it! 🤩 Cannot imagine coming back to Sketch, Illustrator, or InVision, and throwing a hand-off on the developer’s desks. You might say I’m biased, that’s why the next point.
- We managed to raise the built quality and lower down the cost of development by roughly 500%!
How do we measure the cost benefits?
We take the delivery timeline, the number of developed features, rounded salaries, and we compare them between projects. Important note, these are projects implemented with Views. We don’t develop in pure React anymore, so we don’t have stats you might have. It would be very beneficial for other readers and me if you share your numbers with me. I will anonymise the source and with your permission, add the results here.
There are two reasons why we’ve managed to lower the cost so drastically:
- We’ve cloned the DDC platform and reused many elements on the admin side and in the DevOps. Regardless, those stats still speak to the speed of change which would not be possible in the pure React model, don’t even mention the MVC architecture. 🙀
- We’ve learned a lot during the development of the DDC project, we’ve created many design patterns, and reused them in the Urgent Hub project.
Disclaimer: It took us another week to improve the UX, implement calendar scheduling, and most of the virtual visit feature. That’s why you can see the offset to 500%, which is calculated based on the cost per feature. In case of the Urgent Hub, it’s ~160 US$ instead of ~110 US$ (to accommodate the additional week), and it’s compared to ~3200 US$ from DDC project.
How do we measure the quality benefits?
Low cost of change and fast iteration cycle are the most significant factors in the quality improvements that we are noticing:
- Designers directly contribute to the code base by shaping the state, the flow, the look, and the interactions of the interface. Their attention to detail transforms interface into beautiful user experiences without any hand-off, communication, or tickets for the dev team.
- Designers don’t have to take into account additional time for implementation of their new ideas. Every new experiment lands in a testing environment. After testing, anyone can release the new feature to production and start collecting the feedback from the real users, in the real-life context. It’s rapid prototyping on steroids!
- Engineers can depend on Views declarative state machine because of the highly predictable nesting.
Is Views framework available?
Yes. The core of Views, the Morpher, is open source and you can start using it right now.
You can embed Views in a pure React app or a React app in the Views app.
We also welcome open source contributions. 🤝 🎉
Ok. That’s that. A designer is preaching about software architecture. Wow!
