After vanilla react, what front end technology should I learn?

Last monday I finished the great scrimba course on React and I am working on 3 different small projects. I am happy to carry on coding for a while I missed tinkering!

But I know there are a lot of libraries and frameworks that seem to be useful and popular with React.
You have Redux, then you have Flux, then you have the context API. Then you have hooks! , then you have, react router.
What is the most useful to implement on small projects?
My plan is to make some small full-stack projects soon. Something tiny. Weight tracker and things like that.

1 Like

I would definitely learn Redux - that is very widely used and will be expected that you know how to use it on most React jobs… And then I might look at Redux Thunk and Redux Saga. They are both ways of handling async actions in Redux. Thunk is a little easier (imho) but Saga is a little more powerful and more easily testable (imho). I might also recommend a testing framework like Jest and or Enzyme. Redux Form might be a good thing to look at, too. You don’t have to be experts in these, but it will impress employers if you took the time to learn a little testing. And keep learning what React has to offer, all the new things.

Other than that (as you mention) just build things. Build, build, build. Even if it’s a dumb idea, it can be well built. The real education I got was when I built things and had to solve problems and find solutions. And when it came time to search for a job, the most important thing they wanted to see was what I’d built. Just build things.

3 Likes

If you haven’t used React Router in a project yet then I don’t think you’ve built a SPA, I’d say do that first. After that you will have a better understanding of React and a good idea of why you would need something like Redux.

Try also connecting to an API and make AJAX call to manipulate data. I would also advise you to learn backend before jumping into more frontend frameworks that you probably don’t need right now, knowing how the backend works is super important.

2 Likes

Good point, React Router is a must in there.

There are of course other libraries that are good to know, like Bootstrap for React and Material Design. In general, maybe an i18n library, some graphing libraries, and GraphQL is getting hot. Firebase or something like AWS is cool too.

Just keep learning. Pick up a new library and try to figure out some project you can use it on.

Yeah, as Gilbert said, backend is important. I assumed you had some because you mentioned “fullstack” which to me implies building the server too. But understanding how those work together is important. Most frontend jobs I see expect you to have some backend experience.

1 Like

No, we don’t. Hooks are still in alpha :nerd_face:

For small projects you won’t need anything except Router. Everything else will be overkill.

Another questions is which libraries should you learn? I’d say all of them. Seriously. Create a project using context, then rewrite it using Redux, then using MobX. Learn testing. Add React Router, replace it with Reach Router. Learn testing. Rewrite using render props, then using HOCs, then hooks. Learn testing. Add Flow or TypeScript. Learn testing. Check local job boards and see what technologies/libraries are required. Learn [about] them. LEARN TESTING!!!.

Ive taken it easy, learning as much as possible about React before moving on. I just completed my third project in it, feel really comfortable with it and ready to move forward. Definitely learn react router…thats a really, super basic thing to know to create SPA. I’d get a handle on that first.

I had started learning Redux awhile back, but back then, I was still trying to get a grasp of state in React, it was just too soon. Im eyeballing GraphQL really hard though. It seems to come up in nearly every job listing I come across, usually as a “nice to have” but I reckon it wont be long before its an in-demand skill. Kinda want to get my hands on it while its something that will help me stand out.

For full stack, I chose to go the route of Node, Express and Mongo. I completed one project in MERN stack, but kind of limped through it… I want to understand it better, so thats the next thing Im diving deep into. Mostly torn between Redux or GraphQL afterwards…Im leaning towards the latter, just cause Im so interested in it.

…and D3.js. Omg, I’m hopeless :joy:

Anyway, didn’t answer your question outright, but hopefully insight into my experience helps a bit. Here’s the MERN stack project I just finished…its so obviously Materialize…which is annoying to me, but I didnt want to put too much effort into making the design…its a tutorial that I fleshed out a bit to make my own. https://feedback-server-cnd.herokuapp.com/

Here’s the React app Im wrapping up…this one I did on my own from scratch, API’s up the yahoo, also Materialize but I put effort into designing this one, also used Sass. http://clickiton.surge.sh

2 Likes

Last night I coudnt help but keep watching webdev videos on bed[facepalm]
Web Bos video on Context API The Context API is super clear and straightforward! I am not going to use it now but I am glad to know it is there.

Imo focus on learning the rest of the API that’s available. There isn’t much — React has a very small API. There’s Context, there’s preventing unneeded rerenders with PureComponent or React.memo, there’s loading components on the fly with React.lazy and Suspense (Suspense will also handle data loading once they settle on an API at some point later this year, which will be massive). Plus there are a few useful lifecycle methods that are worth checking out.

Learn to use the React dev tools in the browser. Key thing I would say is make sure the rerendering highlighting is turned on. It flashes on every element that rerenders, which gives you huge hints as to what you should look at when optimising in the code (you want as few rerenders as possible).

Context is very good, and very usable (if not quite there yet).

Do install the latest alpha and play around with hooks: they are going into React at some point in the next month or two and are generally fantastic, the API is very easy to understand. They tend to seriously reduce the amount of code you need to write to Get Stuff Done.

As @jenovs emphasises, learn to test the code, this is super important, much moreso than learning other libraries in terms of immediate benefit. If you’re using create-react-app, Jest is fully configured and ready to go, and will handle most things you need. Enzyme can help, but imo learn to use Jest well first, then you can more easily see what benefits Enzyme gives you. Cypress is also worth looking at for UI integration testing.

CRA works with Typescript out-of-the-box, so maybe look at that — there are certain benefits to using a typed language. A certain class of bugs become impossible. It has some downsides; it isn’t perfect by any means and code becomes pretty verbose. But a major benefit is that, particularly if you use VSCode, your editor gets some superpowers with regards to editing/refactoring the project as a whole. Flow is the other option, but note it looks like it’s dead in the water, major projects using it are moving to Typescript en masse.

Bear in mind that dependencies are liabilities. React itself is a dependency, then every further thing you add on top is a dependency of that dependency, each with its own API. As was mentioned, you can do a helluva lot of stuff just with React + just writing logic in plain JS: look at supporting libraries when you’ve hit a brick wall in terms of trying to do something. Like routing — first figure out if you actually need it. Then see if you can just use the browser history API. Then maybe use a wrapper around it (ReactTraining’s history library is a good choice). Then if it’s still painful, look at something like React Router (…which is built on top of the history library, which is built on top of the browser history API). Reinventing the wheel is useful when you’re learning: you have the luxury of time, of being able to see how it works at the lowest useful level then working up from there.

2 Likes

Wahey! That is excellent news :tada::tada::tada::tada::tada::tada::sparkler::confetti_ball::tada::tada:

But it can be a great way to learn them. I didn’t need Redux on some of my first projects, but using it helped me learn it so I was ready with it on my bigger projects when I needed it.

1 Like

Yep, that as well. I’d say (what I would go for in brackets):

  • a routing solution (History/React Router)
  • a state solution (Redux, though Context should do for simple cases and should do for complex cases once it’s finalised)
  • dev tooling for the state solution
  • an immutable state library (Immer, by quite a long way)
  • possibly GraphQL (in which case probably replace Redux with Apollo)
  • testing (Jest + Enzyme + possibly Cypress)

Would definitely be useful

One thing though is that it’s often quite difficult to see the point of a lot of things until the issue they solve is encountered (Redux being the canonical one, if I see another counter tutorial again it’ll be too soon…). And that people reach for things without really understanding if they’re needed or not (orlften just following tutorials online). Also the you start to seriously get into version issues, ever-decreasing quality of documentation, etc.

@josepagan you mentioned Flux: that isn’t a library, it’s a pattern, just a description of a way to structure your app: Redux is the best-known implementation

2 Likes

Just wanna let you know Dan, I just finished implementing redux into my movie app and you really helped me figure out what to focus on next with React. You gave a really great to the point description of what and why. Thanks!!! :blush:

2 Likes