Hey, Adam here! I thought I'd drop in and let you know how the month has been going since last time, and what I had planned this week. Also, I wanted to send through my interview with the very excellent full-stack JS dev and instructor Kent C. Dodds.
If all of this sounds fun, sign up for a free 14-day trial here (you can cancel any time).
Modern JavaScript Update
We're now a week into the Modern JavaScript month, and things have been great so far. Last week I introduced the subject overall, as well as the three dominant JavaScript frameworks, React, Angular and Vue, to provide starting points, free books from SitePoint, things to work on when you're hitting your stride, and some tools and libraries to make it easier. These have been updated over the week as more stuff is uncovered (today, for example).
I also covered state-management and GraphQL, and sent through an interview with Chris Coyier (you may remember that bit, since I also sent it to free members). Today I'm sending through a second interview, this time with Kent C. Dodds!
This week I'll cover design patterns, promises/await, toolkits, and Next.js.
Meanwhile, the normal wide-ranging email has continued to go out to everyone, and covered links like Deno, Node-creator Ryan Dahl's new project, clean code techniques everyone should know, and a collection of weekend reads.
Again, if this is interesting, you could always sign up to join the fun! (14-day free trial, and cancel any time.)
Anyway, enough from me, here's Kent….
Modern JavaScript changelog and Coming Attractions
Today:
Today we have an interview with the knowledgeable and insightful full-stack JS dev and instructor Kent C. Dodds!
I also just added a few links to the React the frameworks section of Modern JS:
Upcoming:
This week we'll be delving into to design patterns, promises/await, toolkits, and Next.js.
Kent C. Dodds is a full-stack JavaScript engineer at PayPal. But that's not all! In addition:
Phew!
He likes his family, his dog, coding, JavaScript, automated testing, and React.
Which dev/tech idea or trend excites you the most at the moment, and why?
That's hard for me to choose! I'm excited by a lot of things in the dev/tech world. Babel (especially with babel-plugin-macros), React, ReasonML, toolkits, and more. Of everything, I think I'm most excited by toolkits. Toolkits encapsulate tools together into one cohesive experience to enhance developer productivity. EmberCLI, Angular CLI, and create-react-app are examples of toolkits. I'm working on one at PayPal and it's been fantastic for developer productivity.
We have some amazing tools in the JavaScript ecosystem, but understanding each one and wiring them up is time consuming and not altogether necessary for shipping apps. Toolkits enable people to focus on the parts of building applications that are hard to generalize (provide real value) without being distracted by learning, configuring, and keeping all the tooling up to date.
There are quite a few toolkits out there. Which one you use depends largely on your current framework preferences. There's actually a maintained curated list of toolkits that you can find on GitHub called awesome-toolkits. There are toolkits for all the major frameworks (and even some minor frameworks). Some items listed do more than others and with the toolkit I'm working on at PayPal, I prefer to consolidate those tools even further to make a great experience for developers with common use cases.
As far as whether you can build your own, I highly recommend it! Often if your company needs to make more than a few applications that are similar, you'll find yourself creating a "boilerplate" repository. Instead of doing that, try to create a toolkit that can encapsulate all the boilerplate. You can read more about my philosophy around toolkits in my blog post "Tools without config 🛠 📦" and a little more in my later blog post "Concerning toolkits 🛠 📦."
The fundamental idea is that you want your tool to come with as many useful defaults as possible, but also to make breaking out of the defaults as straightforward and obvious as possible. So while paypal-scripts (my toolkit at PayPal) comes bundled with an ESLint config, if someone wants to use their own, they simply create an eslint config file and paypal-scripts will reference that one instead. In addition, you want to make it possible to extend the built-in configuration as most people prefer to add or slightly modify the built-in config rather than completely replace it, so paypal-scripts allows you to do this for each tool as well.
Which dev/tech idea or trend is overrated, and why?
Redux is way overused and overrated. Too many people use it without really understanding the problem that it solves and therefore they incur costs for solutions of which they have no need. I don't think that we've given component state a fair shake. Especially with the new context API, the prop drilling problem in React can now more easily be solved with React itself without additional heavy abstraction.
Can you explain the prop drilling problem?
Prop drilling is the process by which you have to share information and callbacks between components that are in different parts of your React tree. For example, if you have some user information that's needed by the chat component in one part of your application, as well as the avatar component in another part, you need to "lift" that state up to the least common parent of those components which can sometimes be fairly high in the React component tree. This often requires any components in between to act as proxies to accept and forward along the props to get the data where it's needed. My most recent newsletter/blog post called "Prop Drilling" explains further what prop drilling is and in what situations it can be a problem.
In my blog post "Application State Management" I talk about how Redux was never intended to solve the prop drilling problem at all and the fact that it does is happenstance. It's not inherently bad to use Redux to solve the prop drilling problem, but because there are other solutions for the prop drilling problem, I find Redux to be among the most costly solutions to the problem and honestly not worth the cost.
Now, Redux does help resolve some problems, as I mention in the blog post: "The problem flux (and therefore Redux) is intended to solve is predictable state flow, improved state debuggability, and simplify the calculation of derived data across stores. It does this through a clean separation of concerns and unidirectional data flow." So if your use case has those requirements, then using Redux to solve those problems for you is great. If all you need is access to your state across your application, then I suggest leveraging the raw context API in React, or something built on top of it like Unstated or react-copy-write.
Describe (or link to!) something cool you built, designed or produced recently. Why is it cool, why are you proud of it?
I spend a lot of time in the open source world, building and contributing to stuff. Recently, I created the react-testing-library (and it's parent project, the dom-testing-library, and sibling cypress-testing-library). What makes these testing libraries so cool is the guiding principle: The more your tests resemble the way your software is used, the more confidence they can give you. With that as their guide, these libraries enable you to write tests that are both maintainable and give you solid confidence in your application's stability. UI tests are notoriously difficult to write well and maintain, but the utilities provided in this library make it infinitely easier to know what to test and the end result is something that people will still understand in a few months.
How did you build it?
In preparing for my Testing Workshop which I've given for Workshop.me and Frontend Masters, I was working on how to teach people Enzyme (the de facto standard library for testing React). The problem was that there was just so much unnecessary complexity and abstraction with that library that I struggled with it a bit. Additionally, I only really used a fraction of what was available from Enzyme anyway because so many of the utilities from that library encourage testing implementation details.
Because of this fact, I had developed a small file of utilities that helped me when testing with Enzyme. I decided to package that up into a library and realized that I didn't even need Enzyme at all because the raw APIs provided by React were enough for what I needed. So I put the utilities into a small library (it was only ~30 lines of code to start) and released that and used it for my workshop.
That was just about a month and a half ago and since then it's received a huge amount of attention, feedback, and contributions. I got great feedback from a few people and was able to add some more utilities that really enabled a much more useful API that enable the guiding principles even better.
Shout out to Greg Bergé for inspiring several of the utilities that make the library as useful as it is. Also Jamie White and his talk "Say More" at Ember Conf 2018 which inspired several utilities as well. Other shouts out to especially significant contributors: Łukasz Gandecki, Ivan Babak, Ernesto García, and Alex Krolick.
What's the best tech thing you read, heard or watched recently. Why was it the best?
Sneak Peek: Beyond React 16. This is about a talk by Dan Abramov that he gave at JSConf Iceland 2018. I woke up at 2:00 AM my time to watch it and was not disappointed. Very exciting things coming to React soon. The demos were so good and the explanations were amazing.
What was the most funny or interesting off-topic link you've sent to a friend recently?
And there's another interview, all done and dusted in just the blink of an eye! Thanks to Kent for discussing toolkits, explaining prop drilling, and generally being a legend. Follow him in his various venues and get more of that good stuff!
No comments:
Post a Comment