-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improvements and Suggestions for React Best Practices #267
Comments
@ivankruchkoff I agree we could touch on some of these topics better. Maybe you can work on a PR collaborating with @timwright12 ? |
I generally agree there isn't much value in this as it currently stands. Being still quite new to React myself, I didn't find here what I generally expect from our best practices, which is definitive guidance.
I completely agree with this. Deferring thinking about routing sounds like a fine practice if speed is the priority, but a poor way to architect a robust, stable application that's a pleasure for a retainer team to maintain for years after the build. A few other things to possibly cover:
|
One thing that's important to remember in this document is that we're not replicating the normal React docs and it shouldn't be a React tutorial, it's more so how React is generally integrated into common projects at 10up. However, it would be great to see some PRs and improvements now that we've worked on a lot more React projects @ivankristianto @MatthewEppelsheimer |
@timwright12 I think @ivankruchkoff points out some pretty valid points here. The above points generally come out in code reviews, especially elements like PropTypes, PureComponents, Stateless Functional Components - a lot of green engineers to React wouldn't be able to deduce from the React docs the correct application/context of these concepts without some on-the-ground experience of working on React projects. I'll add some PR's today that would address some of these |
Agree with the above. I definitely think this page warrants another look, especially after recent convos about the various routers people have used across projects, as well as the new Hooks and Context APIs. Paging @magnificode as this might relate to ongoing efforts on the React project scaffold. |
@timwright12 @dkoo I'll be taking a look at this today. Going to reformat our approach to state management (including some Context documentation), and make some updated recommendations around Routing. |
I'm looking through the React documentation, and it reads more like:
Here are some terms related to React that you should further research, rather than here are some DOs and DONTs for React.
Here are some things that may make sense to cover:
Universal/Isomorphic Apps, the tradeoffs to be made, this influences your routing and state management choice. I recommend completely removing Server Side Rendering, because I think it only makes sense to either have a client side app or universal app, rather than client side code + server side code.
State management: when to use Props, Apollo, Redux, or other for state management, and how the first question about universal apps impacts your choices. How to hydrate state in a universal app to avoid refetching already rendered code. How and when to persist state locally.
Routing: Why the blanket recommendation of React Router, does it work in a universal context? I also don't think it's a good idea to suggest building the components without a router first, it's easier to change routes than to add a router mid project.
React vs Preact, are they interchangeable, when to use one over the other
Higher order components, how and when to use them.
Stateless functional components, how and when to use them.
Pure components, how and when to use them.
Building / bundling / serving your app
How to setup code splitting so you're not bundling a large monolithic bundle, but just the bare minimum for rendering the current page you're on / where you will most likely go next.
The text was updated successfully, but these errors were encountered: