If you're thinking of using React but are overwhelmed by the number of resources, have given up resisting the noise, or just want to keep abreast of the state of things, read on. If you already use React, hate React, still want to resist React…read on anyway for cliff notes on this weekend's gathering.
A bit of an over-react-ion
[author_more]
There is probably nothing that can be written on the subject that hasn't already been covered. Reading every resource in the awesome react repo is equivalent to completing the whole Encyclopaedia Britannica cannon. Time-consuming, impressive and enlightening. However, we only have until Saturday to avoid embarrassment and a coded tutorial isn't going to cover all the buzzwords likely to crop up.
Just tell me what React is, please
Ben Backbone says, "It's just the V in MVC so it's only 1/3 as good".
You say, "I find comparisons to MVC unhelpful nor intuitive, I play with Lego and focus on making beautiful blocks that can fit anywhere".
This is a building block:
({ someText }) => <div>{ someText }</div>
React is not a framework, it's a library which allows you to compose these building blocks to build maintainable interactive interfaces.
Now you're probably wondering why React is so daunting and why the scroll bar is far higher than you were hoping…well, like camping, you can't just go into the woods with your bivvy, you need this…and this…and this…
All I want for JSXmas is you
Alan Angular says, "You're putting HTML in your JS and are mixing concerns".
You say, "You're drunk Alan, go home…but also, it's a delightful way to express markup that can be transpiled to many things, looks like HTML so there's no new DSL I have to learn, and really my only concern is presenting a view of my data".
Yes JSX has probably taken the brunt of hatred, but it's what really set React apart and has now been adopted by other libraries. No more low level fiddling with the DOM, checking for attributes or worrying about cross browser quirks. I can write something that eerily looks like HTML but I can also use good old JS to manipulate it.
Virtual DOM, DOM, DOM, DOM, DOM
Edward Ember says, "The Glimmer engine repaints are far faster than the Virtual DOM".
You say, "While performance is a concern for me I very rarely/never build apps that need to render 10k ever changing list items. If the tech ticks the community, stability, maintainability, testability boxes, it's probably not dog slow.".
Interacting with the DOM is comparably slow, in that it usually takes up the most amount of time in a given operation compared to JS in memory. The React team developed the Virtual DOM (VDOM) to allow them to make a fast comparison of state changes in order to minimize the amount of slow work that needs to be done.
I don't know art, but I know what I like
Charlotte CSS says, "Inline styles are everything that's wrong with the internet. No :before/:after, patchy @media print support, un-DRY code, mixing concerns [Alan +1], extra overhead for :hover etc. need I go on?".
You think, "This all pales in comparison to the fact they don't even work with a strict content security policy *, glad she didn't mention that".
You say, "That's quite a lot of hyperbole before desert. Pseudo selectors are a hack anyway, I prefer not to use them, I like trees, DRY is what I don't like about your blanket CSS and once again, I'm just concerned with using my presentation layer for it's intended purpose".
Ok, so you don't have to use inline styles with React, you can be less bold and try CSS Modules (if you enjoy long class names in your HTML), one of the many CSS inlining tools or just–use–BEM.
I strongly suggest you give it a go though, it means your component's content and style is tightly coupled (which is what you want) and can be dropped in anywhere with confidence. Developers don't accidentally tread on each others feet and there's no ungainly naming convention that must be taught and has to be policed. JS is also great at doing the heavy lifting for animations.
* to avoid this ever so slight wrinkle you can use the Shadow DOM, take a look at react-shadow or maple for ideas.
You ‘n' I flow in the same direction
Kevin Knockout says, "With two way data binding you get highly interactive interfaces with little boilerplate code".
You say, "A unidirectional data flow is half the headache, debugging and testing in one direction is much more pleasurable, especially with pure functions that have no side effects".
So we have our building blocks written in what looks like HTML, with their own protected styles and will only update the DOM when they have to…but how do you make them show stuff? By using idempotent render functions with referential transparency that are as pure as un-driven snow of course ;-)
If you only remember one thing for the party, it's this core concept, React components are just functions. If you give them the same input, they should return the same output, you pass this data via props. However, components can also maintain their own state, which should be treated with kid gloves.
In a React application you ideally want one source of truth, smart components (which know about data and how to pass it on) and dumb components (which know nothing and do as they're told). The majority of your application should be made of dumb components, the worker bees, with higher order components orchestrating data to pass to them.
Continue reading %Bluff Your Way through React at the Dev Christmas Party%
by Craig Bilner via SitePoint
