Arguably, Self Governance is one of the easiest ways to control Chaos and master Sustainability and Scalability. Be it Government of a Country, a community or even a team of 10 employees that you and I are part of.
One day I read about the experimental town of Auroville which is a home to 2000 individuals from 40 countries. Auroville has a branch of government called Resident’s Assembly which is comprised of all its legal residents. This experimental town is one of the most peaceful towns in a country that is tormented with corruption and hatred.
This got me thinking and ultimately became my motivation behind creating Self Governance Design Pattern.
This design pattern can be employed in any framework but all the examples provided in this series will be based on React. If you have employed this design pattern in any other framework please comment about. I would love to hear your opinion.
If you are a video tutorials kind of guy check this out (I would suggest reading the article but it’s up to you):
I have divided this into a series of medium articles, feel free to jump ahead.
- Introduction and Ideology
- React Example — Setting up the UI
- React Example — Setting up Data Flow
- React Example — Setting up Field Interaction Rules
We will be talking about ideology of the Self Governance Design Pattern in this post. Following posts will be focusing on examples.
Ideology is quite simple. Every entity in a Software System should do only 1 thing and they have to do it utmost precision and elegance. A UI element should only render UI and update itself when interacted with and not worry about handling field interaction rules or state management. At the same time SGDP does not mandate developer to fix on to a certain technology while choosing one for the task. It doesn’t ask the developer to use Redux as state management tool in the UI nor does it ask you to use Rails in the back to build your services. All it says is, make things functional and make sure they stay functional though-out the life of the project.
Let look at how this system spans out from a UI perspective. Do not tell the fields how to render and what to render. Let them decide what to do when someone interacts with the field. Let them decide how to fetch the data to render, only tell them where to fetch the data from. Equip them to fetch and update themselves when required information is given.
For instance if there is a page with 10 text fields, just give those fields style to render, path to fetch the value from state and a callback to call when interacted with. So in the future if the project management team decides to change the look of the components them selves, all you got to do it change the Shared Components that are rendering your UI.
Also since each field maintains itself, in case of Redux or React Context as state management tool, only the fields that have changed will re-render. This will increase the responsiveness of the UI since the JS Engine has less elements to update. This by itself is a major advantage of the SGDP.
There is another benefit of this pattern. Have you ever wondered how New UI and Old UI structures work (like Flickr, Meetup). We come across UIs where there will be an experimental UI or new UI that they want the users to use but if the users are not happy they can switch back to older UI. With SGDP since the UI, Actions, Rules Management and Data flow are separated out, switching between UIs is very simple.
Don’t believe me? Check out this codesandbox to see my claims in action.
In future articles you will be receiving in depth view into how such UI is built and how you can build one yourself.
SGDP’s Ideology only mandates 2 rules:
- Every entity in the software system should only do 1 function but it has to perform that with at-most precision and elegance.
- Developer can choose any technology of his choice but when he/she uses them, Rule №1 has to be applied.
That’s it. That’s all there is to Self Governance Design Pattern. In the next article we will be looking at an example using React and Redux.
You can reach me at: