Re-rethinking best practices with React
What this talk is going to be about?
I am going to go through certain established practices that were the norm before React came along and showed that there can be a better way to do things!
I think if I have to summarize my entire talk in a single line it would be this:
Innovation cannot happen if we are bound by the ideas of past!
The MVC Pattern
-
In order to create a UI one had to maintain three things i.e model/view/controllers, even the frameworks that came before used this pattern heavily.
- On the outset, it seemed like a clean way of separating logic or dare I say concerns :-). But at scale, this becomes quite hard to maintain i.e. if you need to compose to two UI bits you need to make sure that mode/controllers/view were in sync.
- Instead, React came up with the Components wherein we don't think of things in terms of model/view/controller but rather just one unit of UI which encapsulates all that it needs. This model reduced the number of things one has to keep in my mind before trying to compose.
JSX - Templating
{{#list people}}
{{firstName}} {{lastName}}
{{/list}}
/// The data :
// {
// people: [
// {firstName: "Yehuda", lastName: "Katz"},
// {firstName: "Carl", lastName: "Lerche"},
// {firstName: "Alan", lastName: "Johnson"}
// ]
//}function People(props){
return (
<ul>
{props.people.map(({ firstName,lastName }) => <li>{firstName} {lastName}</li>}
</ul>
)
}JSX - Templating
- No need for worrying about selectors if you want to interact with some HTML element from JS
- Removed the need for keeping a separate file where data was maintained.
- No need to learn another language altogether! Just use JS!
- Logic and UI can now be colocated which means no more context switching!
The norm that JSX broke was keeping JS and HTML in two separate files. In doing so when it first came out it was met with sharp criticism from the community.
But slowly people started realizing the benefits of mixing them both :
CSS-in-JS
Some benefits this approach gives you :
- No more worrying about specificity
- Code splitting becomes easier
- Conditional CSS becomes easier to deal with
- Theming too becomes relatively easier to do.
- ...
This another similar norm like JSX only this time its with CSS.
This is not from the React core team but it's from the React community.
This is still being debated but whether you like it or not, I think we can all agree that it's different and broke the norm for sure.
This may not be as big as the other ones before it but still, I think it's a significant one when it comes to breaking the norm and also the resulting abstractions due to this approach has made React one of its kind.
Pull instead of Push
Even now a lot of other frameworks prefer to use "push" based approach instead of "pull" based i.e. they update the UI as in when the new data is available contrast that with React where it takes control over when to schedule those updates.
Pull instead of Push
A direct quote from React document :
There is an internal joke in the team that React should have been called “Schedule” because React does not want to be fully “reactive”
Because of this kind of approach React is able to bring in features like Suspense and Async Mode without changing the interface. The performance itself becomes abstracted away from consumers.
What's up with the Suspense?
If you have ever worked in a big enough React project I think you would have come across a common component usually called as "Loader" which takes in a URL and fetches the API and manages the loading/error states for the users.
Since we are in components land with React most App's ended up with stacks of loading indicators and then some UI. Which made for an awkward UX and not to mention very hard to do things like timeout and code splitting on top of it.
What's up with the Suspense?
Having seen this issue React came up with this neat API wherein you can define your remote dependency inside the render function and wrap it a <Suspense /> component and few other parameters and you can show just one single loading indicator for the whole tree under the <Suspense /> component.
Which basically means they broke the norm of keeping the render function pure!
And this just one of the features that can be done because of the pull-based approach.
For more info on this, you can watch dan's talk
Hooks
This is one of the latest features of React which lets you add a state to function component i.e. previously if you had to add state you would have to convert a functional component to a class-based component but now you don't need to do that.
Again the norm that functional components had to be stateless was broken! We used to call them SFC's short for Stateless functional components - they no longer are stateless!
Before Hooks:
After Hooks :
The Full Circle?
Courtesy: Sunil Pail 's talk at react-europe
The Notion Of Best Practices
I got the inspiration for this talk from Sunil Pai's talk last react-
A good personal example I can think of is personally I tried to solve the "Loader" problem by creating the best Loader out there but no matter what I came up with had some or the other trade-off which didn't really solve the problem.
The Notion Of Best Practices
React solved the problem by actually throwing Promises from the render function! I mean of all the things I did to solve that problem this approach would never have come to my mind! Why so? Because using try-catch as a means to control the flow of the program is something really unheard of and also considered as bad practice to be avoided.
But turns out given a certain constraints and a environment doing such a thing as throwing a Promise actually resulted in a much cleaner abstraction than I could ever create!
The Notion Of Best Practices
So does that mean I recommend abandoning all best practices? No of course not what I am recommending is not to be constrained by them when thinking of trying to build something new!
So then the best practices that React broke were never best practices? No not at all at a time when they were conceived there would have been some context due to which they were there but overtime that context is lost or not really carried over well and instead of being a guidance they can become somewhat of a dogma!
The Notion Of Best Practices
For example let's take JSX where the best practice of keeping HTML and JS separate was broken. If we didn't have the model that React gives you i.e. where you do the DOM manipulation yourself instead of the framework doing it for you.
It would most likely would have been a disaster!
So the previously held best practice is still best practice if we are not using React or similar framework!
Conclusion
Let's not be held back by established practices when trying to create new best practices!
THANK YOU! 😃
deck
By varenya
