Initial RFC: Scope and Goals #1
Replies: 13 comments 18 replies
-
Having setup a greenfield project recently, I can confirm setting up a React project for an enterprise requirement is a nightmare. There are dozens of tools in the React ecosystem to do pretty much everything and the community has divided opinions on each of them even if they solve different problems altogether. The part of the React docs about toolchains is supposed to help with this but let's admit it, most React devs have never even seen it. The fact I dislike most about the React docs is that they fail to mention explicitly the pitfalls of create-react-app, a major one being that implementing any server-side rendering or adding things outside of that one root div with it is a sparsely documented herculean feat, unless we use third-party solutions like react-helmet, which haven't been maintained in years. And this is a problem with many other aspects of a React app. There is so much dependency on third-party solutions to efficiently achieve anything but the official docs have no opinion on how to do anything in a large scale app. For comparison, Express and Redux are supposed to be unopinionated as well but they both have a best practices section to help beginners avoid making really well known common mistakes. This initiative can help solve that. It can help people understand react-query isn't a state management tool, it can help people understand what XState is for, what ReduxToolkit does, what Apollo does different than SWR, what server rendering is & why most corporate apps probably need it in some capacity, how to just get some data from backend without dumping a temporary copy of database in your redux store and hundreds of other common things almost everyone is confused about. |
Beta Was this translation helpful? Give feedback.
-
There is no good unopinionated guidance on libraries, so such site definitely can fill the gap. I think this can be helpful for both newcomers and experienced developers. Use cases:
It would be good to start with some overview laying out foundation for further guidelines:
Then it can continue with guidelines for specific problems:
I like how @leerob structures his posts with comparisons: Also, some libraries have own comparison pages (Chakra UI, React Query) so maybe this site should link to them if it would compare libraries |
Beta Was this translation helpful? Give feedback.
-
I have the impression that people in general seek guidance of how to do stuff correctly, because the ecosystem and features of React can be quite overwhelming. If you don't have a good idea of data fetching, state management, data structures or how build-systems work in todays JavaScript world it's hard to figure out when to use X and when Y? Example: Should I use But we have to be also careful to not go into "taste-topics" like: Should I use SASS with CSS Modules or CSS-in-JS? Styled Components? What should I pick for my giga-mega-highly-complex-and-special-app which contains at least millions of files? I think it makes sense to make categories, something like:
|
Beta Was this translation helpful? Give feedback.
-
I think we could look a bit at how awesome lists work: State management
Tooling
and then have something like a checkbox to select them and be able to compare their pro's and cons side-by-side. If you combine that with tutorials like
Which mixes and matches different libraries so you can see the difference. It could contain Redux and MobX so you can see exactly how different it is in the context of such an app. Or even
And then showing the difference between hooks, MobX and for example Apollo would be really helpful I think. As for moderation, we could approach this with flat files. Something like markdown + frontmatter for meta data like tags etc. Authors would then simply make pull requests to add their library and the reviewers could then triage. Markdown would allow authors to add examples and context while still adhering to the styling of this tool so it's a more streamlined experience. Frontmatter would allow authors to add tags like Something that would also help is getting respected community members on board. This would combat questions like
|
Beta Was this translation helpful? Give feedback.
-
I have two opinions on this.
But anyway, this is such a great initiative. I am sick of having to compare a shit ton of options myself when I stumble upon an issue that I have not solved recently. |
Beta Was this translation helpful? Give feedback.
-
I'm thinking there should also be clear guidelines to adhere to if someone would like to add content featuring certain libraries. This makes reviewing/regulating easier and prevents getting bombarded with libraries that don't really add anything. I think it'll be fun if this takes off to look at the side effects. Instead of creating yet another fetching library that's the same, we might actually start seeing different stuff. |
Beta Was this translation helpful? Give feedback.
-
Whilst not directly the goal of this initiative, another great thing I can see coming out of this would be some educational content around the whys of all these tools. As a longer-term goal, being able to clearly articulate the core problem each of these tools are solving will empower developers (especially beginners) and make it easier for them to assess the options. One of the earlier commenters stated a site such as this can help people realise that I know when I first started out, "best-practice" type resources where very useful but their usefulness took on a new level once I began to understand the core problem being solved by my chosen tool. |
Beta Was this translation helpful? Give feedback.
-
This is my first time using GH Discussions, and it feels just different enough than Issues to be a bit disorienting :) like, I'm not sure where this additional comment is going to end up thread-wise. Awright, so here's my plan at this point. I've got another RTK docs page I want to finish tomorrow, and then I want to try to create a skeleton for this site for tomorrow. What I'm thinking of is a Docusaurus v2 site, hosted on Netlify, and I can try throwing together a first stab at a page on Redux to help serve as a starting point for us to flesh out the intended content, tone, and approach for this site. As additional next steps, I think we need to:
|
Beta Was this translation helpful? Give feedback.
-
I think for each library/topic it would be nice to include a section of: Here's how you could do this with plain old React. I'm thinking of something like this where David shows how to build a state machine with plain reducers, then as a final point shows where the library comes in handy. You can actually get pretty far just using React, and I think because these third party libraries are talked about so much, people feel like they need to use them right off the bat. In my opinion, you should only use a library when doing it the plain React way becomes unmanageable. Of course, some things become unmanageable in plain React much quicker than others, but I think discussing the plain React way is enlightening because it shows you why the library exists in the first place and why you need or don't need it. |
Beta Was this translation helpful? Give feedback.
-
I think https://www.robinwieruch.de/react-libraries may also be an inspiration? |
Beta Was this translation helpful? Give feedback.
-
@markerikson Do we have some contributors info or something? |
Beta Was this translation helpful? Give feedback.
-
Why don't we just start reading and sharing and passing articles and books by those who have come before us. Fowler, Beck, and 100s of others who came up with stuff before most of all of us were even born....all of which we can use to drive "good practices" in any kind of code we're working in. How about we start listing that kind of stuff in FB docs ay? Start with "Humble Views / Humble Object". https://martinfowler.com/bliki/HumbleObject.html Wisdom for the ages. Figure out how to apply that in React... how can we model good practices like these in React, TS, whatever code we're in. This is really what's missing. Read what's already out there, been there for years. |
Beta Was this translation helpful? Give feedback.
-
If we ask very nicely maybe @jamonholmgren (maintainer of MobX State Tree) could help with the MobX portion and include some portions on MST as well. |
Beta Was this translation helpful? Give feedback.
-
I'll just go ahead and paste the tweets I pasted into the README as a starting point:
What I'm picturing here is somewhere in between a "list of top libraries", a "list of commonly used techniques and patterns", and a "examples for some best real-world best practices and advice to augment the React core docs". The React team justifiably has avoided offering suggestions that extend beyond the scope of React itself, both to avoid appearance of favoritism, and because they want to let the ecosystem thrive. I'd like to put together a community resource that kind of fills in the areas that the core React docs don't cover, offers info on techniques and practices for building real-world apps, and lists the pros/cons/use cases for areas that suffer from fragmentation and "analysis paralysis" ( https://twitter.com/floydophone/status/1365833622700220419 ).
So, this is me sorta putting my money where my mouth is, and creating a repo to start this.
I guess the place to start is discussing:
Additional thoughts:
Beta Was this translation helpful? Give feedback.
All reactions