- The React (JSX) version is merely a syntax change to the components & using react-dom to render.
- (For the demo, the component also renders the state object as a string into the DOM.
- With each component, we can clearly see how data is passed around and what each component’s expectations are.
- Components can be very dynamic, as long as the state is, too!
- Being able to fetch data when a specific component needs it or integrate with 3rd party scripts is an essential escape hatch.
“Teaching React Without Using React.” is published by Eric Clemmons
Over a month ago, our remote team of front-end developers visited our Houston office for meetings, social outings, and knowledge sharing.
This team typically works on WordPress sites using PHP, HTML,
SASS/LESS/CSS, I wanted to introduce them to React, as it’s been the foundation of our major applications for 2 years.
You may have noticed that our team designations of “front-end” and “backend” are less & less sense fitting nowadays. “Front-end” is typically responsible for authoring & theming, while “backend” work on full-stack business applications.
The first question I asked myself was:
For us, the cleanest PHP + WordPress themes still rely on a great deal of
templates abstracted into partials, custom PHP functions for lifecycle hooks,
The first step was to show that templates are visually clearer when markup is grouped, rather than concatenated across several logic blocks.
This simplifies the conversion of static content into rich, dynamic content.
Working at HigherEducation.com, a very common scenario is for a user to search for online programs in their area:
Using this scenario & our preceding examples of functional components, it’s a cinch to draw the lines of abstraction & convert standard HTML into components:
We can continue abstracting away markup into components until we strike a balance between terseness and flexibility:
Components can abstract away as little or as much as you like.
Our render function completely destroys the DOM and re-renders our view to drive home the point that the view is a result of our state.
(To help round out the example, we’re making an AJAX request for the data after our initial render.)
Even further, the Widget component shows a loading indicator until a data feed is provided.
(For this demo, the component also renders the state object as a string into the DOM. This way, as the user interacts with the Widget and the view re-renders, the state is visibly the cause of the change.)
With each component, we can clearly see how data is passed around and what each component’s expectations are.
Lastly, the React (JSX) version is merely a syntax change to the components & using react-dom to render.
The only React-specific change to our benefit is being able to supply a custom onChange to the form, rather than attaching an event listener to the document.body.
Well-designed components shouldn’t need a massive rewrite to work with another renderer.
The selling points of React in comparison to the Vanilla Widget were:
How’d it Go?
The Ah-hah! moment for the group was watching the DOM get completely destroyed & faithfully re-rendered purely from the state.
Although, when you think about it, this is already how PHP & server-side rendering works: the request comes in, the view references the current state of the request (e.g. $_GET & $_POST), returns the output, rinse & repeat.
The key takeaway is that React has changed how we tackle building complex applications. Instead of blindly enforcing DRY or “separation of concerns”, we eagerly co-locate data, logic, & aesthetics with the components that know best so progress can be made, rather than needlessly stifled.