Front End libraries challenge: can I use newer technologies (React hooks, Redux toolkit...)?

JavaScript
1

I’m about to get started on the Front End libraries projects and I was wondering whether there were any restrictions, since the course focuses primarily on React class components and vanilla Redux. I spent a considerable amount of time learning React hooks and Redux toolkit since these make more sense nowadays. I assume the tests will pass but I just wanted to make sure before devoting time to writing the code.

2

Hi @jacques.nikola !

It is totally fine if you use hooks.

As for redux toolkit, you should be fine there too. I personally didn’t use redux for any of the projects but I would be genuinely surprised if the tests were affected by it.

IMO, you don’t need redux for first two since those are really small projects and redux might be a little overkill.

But it is your project :grinning:

1 Like
3

i am also working on the same projects right now and I would suggest you not to use hooks and use class based components instead. I saw people mention that they came across code with class based components in their jobs so, it would be a good opportunity to really learn them now.

You can use hooks in all of your side projects. Like for example the first react project I made, I made it using react hooks using Youtube tutorials and all but here I am about to do the projects using class based components, for learning them. But I won’t be using them for any of my other personal projects like for example I am planning to make an app out of the roman numeral converter code that I made in the second certification and all.

I think I will be using Redux for learning purposes at least the last three projects. (I was not planning to until this post)

1 Like
4

Technically you can use anything you want, literally anything, the tests shouldn’t care much (YMMV). I’d use hooks & toolkit as they’re the de facto standard way of using React & Redux as of now, there isn’t any pressing reason not to; a huge % of the React code you’re likely to see will not be using classes, and that % will only increase. Redux is only really necessary when it’s necessary, and you can normally tell when that is (large amounts of state you need control over). It’s not essential, it’s very useful but IME most React projects IRL don’t use it because they don’t need to.

2 Likes
5

Thanks for the reply. Indeed for some projects I wasn’t planning on going with React or Redux at all but after trying Bootstrap and Vanilla JS, I’m now leaning towards React and Sass, even for small single-page applications it seems less tedious than using vanilla JS/Bootstrap/jQuery. Maybe it’s just a matter of personal preference.

6

Thanks for your reply. I was also under the impression that hooks were the new standard, for good reason. It seems you can get away with useContext and useReducer for global state management in most cases, but we’ll see, maybe I can figure out a way to include Redux in a project here.

7

Thanks for your reply. I also think it’s useful to learn class components to be able to deal with ‘legacy’ code, that’s the reason I found the sections about React and Redux to be useful, if somewhat outdated. I will definitely be using React hooks and Redux toolkit in my personal projects. I also recommend learning a library such as Jest for testing, I came across it in a Redux course I took on the side (as I’m writing this I see this is covered in the ‘Quality Assurance’ certification). This topic is seldom mentioned in the online courses I took (perhaps because it requires a node environment to run) but I think it’s a good skill/habit to have.

1 Like
8

It’s a very useful thing, but yes context can be used for global state. All of these things add up-front complexity, so best idea is

  1. don’t use global state unless you really need it. Keep state as close as you can to the component where it’s used, and then can just pass via props really easily. This is ideal as it’s the simplest and most performant way to do things.
  2. if you do need it, and it’s just very simple (maybe one or two values you app needs everywhere), then a context backed with, say, useState works well.
  3. if it’s more complex, but it’s still one small set of data (like one object), then yes, useReducer – it becomes obvious when you need that if you’re writing many useState hooks (just replace them with one useReducer).
  4. if it’s multiple different sets of data and you need to deal with them all, then at that point you’d be rewriting Redux: not really much point doing that, just use Redux.

As an example:

  1. n/a
  2. you have a value that says whether a user is authenticated or not which can be set
  3. you have an object that contains information about the authentication status and the user, and all the fields can be set
  4. you have objects representing authentication status, user, messages written by the user, etc, and they depend on each other

Edit: and if you needed above, could, say make AJAX requests in the frontend in the app, and maybe can do the above without storing anything globally in a context

9

Hi Dan, thanks for lay(er)ing it out so clearly, it all makes sense now; if you’re dealing with different slices of data, each requiring it’s own reducer, action creators etc. it makes sense to manage them through a store in Redux, if it’s a single slice then useReducer is sufficient. And if the state isn’t shared ‘horizontally’ with other branches of the component tree then prop drilling makes more sense. Nice recap, very helpful.

1 Like
10

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.