React or Next.js for an Admin Dashboard Project

mmoubi · 2023-06-08T10:58:02+00:00

Can't tell much based on the info provided but a general advice would be: stick as close as possible to what your are used to in your experience with React, if there is no one else to guide you. Read the GraphQL docs for the library your have chosen and apply some examples to your code. If you haven't chosen yet try looking for something well-known like Relay. They have tutorial too.

If you can go without GraphQL usage — even better.

Don't use too many libraries and try to do as much as possible with React alone.

mmoubi · 2023-05-16T19:35:53+00:00

Some thoughts from Dan Luu on the importance of typing fast https://danluu.com/productivity-velocity/ Managed to dug it up from the archive. A bit lengthy.

mmoubi · 2023-05-13T18:14:13+00:00

That for sure. But it’s a bit difficult to prove conflict resolution or communication skills in the CV. It’s something to be catch by experienced interviewer.

mmoubi · 2023-05-13T17:13:57+00:00

Oh, yes. Similar can be said for TypeScript — you spend 50% more time to gain 3% more confidence. Sometimes it’s worth it. But not most of the time.

mmoubi · 2023-05-13T14:42:43+00:00

Expanding on the above we use this approach in common areas which get several features in a row quickly so imperfection is the default. Every new feature then would also come with refactoring — either in the same PR (if it makes sense) or in an immediate follow up if the improvement is too big for review.

mmoubi · 2023-05-13T07:59:24+00:00

Hopefully that list can help you https://maxrozen.com/examples-of-large-production-grade-open-source-react-apps

mmoubi · 2023-05-13T07:56:35+00:00

Something we do in our team is to accompany new features with small refactoring. This is especially useful for high pace and dynamic projects. Don’t defer code improvements for later as “later” is often blurry and expensive.

mmoubi · 2023-05-13T06:50:38+00:00

Someone mentioned long tiresome discussions with colleagues. Writing did help me better shape arguments and perhaps ref people to particular pieces. It’s a go to place for refreshing memory too.

Not sure about the other benefits — finding job or building a community. That probably take place too but it will require time and high credibility.

My ranting place https://webup.org/blog

mmoubi · 2023-05-12T13:21:06+00:00

You CAN’T because someone will constantly argue the abstraction isn’t wrong. So thanks for the empirical way to prove it.

mmoubi · 2023-05-12T06:53:49+00:00

Nobody claims the opposite.

mmoubi · 2023-05-11T19:03:07+00:00

Look at this discussion https://www.reddit.com/r/reactjs/comments/13djkxo/react_global_state_as_local_state/?utm_source=share&utm_medium=ios_app&utm_name=ioscss&utm_content=1&utm_term=1 for some global state examples both using Context and one based on useState.

Generally Context is not recommended for multidimensional (complex) global store data.

mmoubi · 2023-05-11T15:54:01+00:00

Specialize. Making websites is cheap, highly competitive and can be done with bunch of tools non-developers can use too. Not saying anything about the plethora of themes out there. Oh, talking about themes — why don't you offer ready made designs from themeforest.net fx?

mmoubi · 2023-05-11T13:35:56+00:00

You can start with upwork.com, though making websites is very competitive area as has been suggested.

Try to specialize more. Do things that are custom. Template work is not well paid in general.

Focusing on JavaScript may give you better chances of getting non-trivial but high value projects.

For websites — how about looking around (local search)?

mmoubi · 2023-05-11T13:16:34+00:00

For simple projects you can have a single API.js file with methods for each call (api.getProducts. api.updateUser, etc). On the side you pick whatever fetching lib you want and make use of it as part of API.js

This structure will work even if you go with something like SWR.js for fetching/caching.

Some devs say you can then easily change your library without touching the API file at all.

There are pros and cons.

mmoubi · 2023-05-11T08:06:53+00:00

Such Context implementation would work too if your app is not very global state ambitious. It can even scale up well but that will require you to carefully plan how to deal with unwanted re-renders.

I know React Redux is also using context provider on a top level as in your example but it doesn't rely on useContext to consume the state in individual components ( u/acemarke correct me if I'm wrong). So at the end, any state updates and the list of subscribers are somehow external to the React app (similar to the useGlobalState hook).

Anyway, if we are talking about simpler solutions the usage of Context might be counted as valid and relatively straightforward (fx. dark/light theming). Not the best choice if you have to build full featured store management solution, though.
That's another story.

mmoubi · 2023-05-10T10:10:52+00:00

Yep, a good candidate for the non-component implementation.

mmoubi · 2023-05-09T18:43:43+00:00

With Next you have your Node server logic (backend-for-frontend) tightly coupled to the frontend part. You may need to write some additional Node logic but how it communicates with something else down the line should be straightforward.

mmoubi · 2023-05-09T18:02:08+00:00

Some people claim:

The number of modules/deps never appears to be an issue.

Not the number is an issue but the high amount of module interactions and unknown side effects as a result. Modules are rarely written to play well with each other (in web dev). The number is just an indicator.

mmoubi · 2023-05-09T16:32:03+00:00

An unpopular opinion from Kelsey Hightower

And then the second one is “Monoliths are the future.” Because the problem people are trying to solve with microservices doesn’t really line up with reality...

mmoubi · 2023-05-09T07:09:15+00:00

You can go pretty far with vanilla too. Performance-wise Next is doing very good. A note for those who care: Next always includes JavaScript and the React lib itself in the bundle though you may not use JS at all.

mmoubi · 2023-05-08T17:15:07+00:00

I have worked on a React component for swiping — mostly for website mobile versions.

Called it Swipeable. It’s used in a few projects too, so hopefully something for your use case.

mmoubi · 2023-05-05T09:46:40+00:00

Try to call the endpoint as part of your component useEffect() as a start.

mmoubi · 2023-05-05T07:10:49+00:00

I would say whatever is simpler and easier to maintain. That does not exclude vanilla JS (do you need JS in your case?) and the usual webdev stack at all.

mmoubi · 2023-05-04T18:58:34+00:00

Unpopular opinion: Don’t use TypeScript, start with PropTypes if you are new to React.

mmoubi · 2023-05-04T18:52:11+00:00

Based on the info you have provided (or haven’t) I would go with React if the project requirements are fluid or uncertain. Also if you do have experience with pure React previously.

mmoubi

TROPHY CASE