In my case, learning Redux has been the biggest obstacle when trying to grasp the overall React ecosystem. Is it still recommended that you learn Redux in 2020?
Cypress versus Selenium
We’ve been hitting lots of issues with testing our app in Chrome vs. Firefox vs. Safari vs. Edge. Things still work differently in some or all of these.
Cypress (and even Puppeteer) only cover Chrome E2E but these are newer and nicer to work with but Selenium gives us more confidence for multi-browser support but is harder to learn/use from what I’ve seen.
What would you recommend and why, regarding end to end testing for large apps?
Redux- custom hooks(useReducer) - react-query
With custom hooks you can hold the state locally and handle state updates using useReducer hook. By doing so, we don’t put the state of a component in Redux but we end up somehow “spreading” the state among each component ending up having somehow the same actions/reducer etc boilerplate. Is this a good practice in general so as to avoid putting everything in Redux?
What are your thoughts on what belongs to Redux and local component state?
Also what do you think about react-query? Could this be an alternative to reduce Redux usage/boilerplate?
Thanks a lot!
Now that hooks are taking over, should we forget about class components when starting a new project?
Should we refactor our old projects that use class components over to hooks?
In your experience teaching, which hooks do you find learners have the most trouble with? Why do you think that is?
I write a lot of NextJS for work at the moment but I feel like Gatsby has a bigger following and don’t see as much interest or resources around Next.
If you were looking for a SSR React solution, would you reach for one of these tools or something else? Do you think the difference in interest/support is down to marketing or something more fundamental?
What are your favourite misconceptions when it comes to testing (unit/integration/e2e/whatever)?
I am working on improving my team’s testing practices. A lot of our components are untested or if they are tested they currently have some really light tests. We still use Enzyme/Jest, but I don’t think we’ll be able to adopt something like React Testing Library while everything is still tied to our current tests. We have some legacy components that have ballooned into massive pieces of work that don’t have many tests.
Do you have any suggested strategies for improving a culture around testing? Any strategies to make it not seem like an insurmountable piece of work?
Hi @laurosilva! I used Redux in one application at PayPal and quickly got frustrated with the amount of complexity involved with making any change for the state that’s stored in Redux. It was a huge amount of pain and I didn’t find it to be worth the effort most of the time even back then (long before hooks and official context).
Now that we have hooks and context, I don’t see many use cases for Redux, or even any state management solution beyond React (especially when you manage your server cache with react-query). Read more here: https://kcd.im/state
In the last few years, I’ve found less and less value out of cross-browser tests. Typically issues stem from misconfigured tools (compilation with babel or polyfills) which are fixed once and then rarely touched again.
If you’re really concerned about it, I find it’s a good balance to write most tests with Cypress, and then have a handful of tests with selenium to double check that the app loads in other browsers.
You might also look at visual regression testing tools like percy.io and applitools which allow you to run your tests in one environment, and then they’ll pull up that same DOM in multiple browsers to take a snapshot. That can help you catch visual inconsistencies between browsers.
Hey Kent, as a full-time educator how do you stay sharp as a coder?
Hi @staurosmpa! I’m a big fan of state colocation and don’t really have much trouble with boilerplate and state spreading all over my app. In addition, using react-query significantly reduces my own state management needs down to just UI state which is often best when colocated anyway! https://kcd.im/colocate-state
I’m a huge fan of react-query.
Hi @nicole.sattler, I haven’t taught or written a class component in over a year (since around the time hooks came out). I would recommend learners focus on function components and hooks and only learn class components on a as-needed basis (there’s a TON of material out there to do so).
As for refactoring, I recommend that on an as-needed basis as well. If you don’t need to change it, don’t bother taking the time.
I see people struggle with
useEffect most. Though, I think people new to React seem to understand it more quickly than people who are used to classes and lifecycles. There’s a bit of unlearning that you need to do with that hook.
Then there are the less common hooks like
useImperativeHandle that has very few reasonable use cases and people should avoid using anyway. But I do teach it and people struggle with that a bit as well.
I’ve noticed this same thing. The community push behind Gatsby has been remarkable. I can create a pretty sweet website just by wiring together a handful of really powerful plugins.
I’ve not done anything with Next in a few years, but if I ever needed to have server-rendered pages, that’s probably what I would reach for first.
As for community interest, I think it’s a combination of terrific marketing on the gatsby side, as well as their focus on the developer experience, documentation, and official/community plugins.
This is a good one! I’ve actually written about Common Testing Mistakes and I stand by those:
- Mistake Number 1: Testing Implementation Details
- Mistake Number 2: 100% code coverage
- Mistake Number 3: Repeat Testing (like, for E2E, every test going through the full login flow)
That last one leads to a misconception that E2E tests are brittle and slow. Yes, they are that if you increase the points of failure by repeat testing, but if you’re intentional about the types of tests you write and you avoid repeat testing then you can avoid some of the brittleness.
Of course, you know all of this
What do you think about ReasonML and ReasonReact?
Do you foresee that it’s going to be a dominant way of writing React in the future?
I have a couple of friends advocating to learn and use it, but I’m still thinking whether it’s worth or not.
What do you do for physical exercise?
I got a few questions.
How to get deep understanding of how react works? A lot of times i end up thinking its just magic, without feeling confident at all.
If you have to optimize react app, where do you start?