-
Notifications
You must be signed in to change notification settings - Fork 470
React starter template #4010
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
React starter template #4010
Conversation
This looks great, thanks |
Hello @MargaretKrutikova! And thanks for the contribution. Though unfortunately we might need to reconsider this. |
@chenglou Interesting insights, thanks for sharing. I think the best we can do from our side is share some feedback from beginners trying to get started with Reason. We've been trying to spread the word here in the Nordics ReasonML community, speaking at meetups, encouraging people to try it out, etc. Unfortunately, the most common feedback I have been getting when following up with developers, is "We've tried it real quick, but [a number of reasons], so we got discouraged and quit". And the new template is coming up as one of the "number of reasons" quite often (see this thread in the ReasonML chat). One of the other most common reasons being documentation. This has come up at the latest ReasonConf too btw: https://www.youtube.com/watch?v=-2FeCQawnGc (note the applause as soon as it gets mentioned 🙃). I've also heard people contrast the learning experience with Elm, where beginners are guided from 0 to a basic app that fetches and displays some data from an API, in a straightforward, step-by-step tutorial. The current state of ReasonML docs, on the other hand, is far from beginner friendly. It would be interesting to hear your take on this, and how you are planning on addressing the issues with the new template in case this minimal version gets removed. P.S.: More feedback has been collected on Twitter not that long ago: https://twitter.com/matzatorski/status/1201537452164493313 |
Thanks for your feedback, @chenglou ! I would like to address the points you mentioned in your comments. Regarding the template being a learning material, I have gotten very negative feedback from a couple of people who I encouraged to try My second point is regarding those of us who already know some I feel like |
The step-by-step tutorial is a bit orthogonal to this, though that part needs to be improved too. The raw dom manipulations were intended. The entry points can be removed without disturbing anything else. If the syntax's harder to read, we can change that instead (and we were trying a while back). I didn't want to bootstrap the entrypoint itself using RR concepts folks might not understand yet, thus the raw DOM manipulations. This can be revisited. I get the points you're trying to illustrate here, but philosophically I really think we shouldn't overfit for the literal first step at the expense of subsequent steps. I care about newcomer experience, but I also care about the learning curve and transitioning said newcomer to an expert. CRA-style templates is great for a first impression, and we can discuss and tweak our react-hooks template to fit that, but it's no help for learning to modify things structurally. The medium constrains the message and all. I've outlined this in the blog post. The old template was also problematic because it didn't show how to use the React APIs. A big chunk of complaint was that there are no example skeletons of proper usages. To cover most of these (not edge-case, but frequent) uses, I've tried distilling them into as few examples as possible, and that's the minimum amount I've gotten. Essentially, as much as I'm all about hand-holding a newcomer through the process, we need to create the architectures that lets people with no direct relation with Reason community, without the opportunity to assist to a workshop, to know the space of APIs and how to use them. This is a non-problem during workshops because those often have a fixed goal and funnel every learner through a predetermined golden path. To extend the last point, one reason why folks can't find authoritative examples of RR usage is because there are too many of them, everywhere, from tutorials to blog posts to userland repos. Ideally we have a single source of truth for good examples. Having more than one template goes against that. Again, I'm open to tweak the hooks template to meet the needs more. But we need to insist on learnability and understandability over a facade of minimalism (e.g. the bundler and the server). There are ways to make the newcomers overcome the fear of a boilerplate, too. Changing the syntax of dom manipulations would be one, but I digress. |
Btw is it possible to talk about this on hangout with the two of you? I'm trying to do more of live streaming-ish kind of talk because I think there are nuances that are hard to convey on text. |
Thanks for the detailed walkthrough - everything you're saying makes sense. It does seem, however, that it makes more sense in a context of "authoritative examples or RR usage", but not necessarily as much for a starter/template-kind of project. "I care about newcomer experience, but I also care about the learning curve and transitioning said newcomer to an expert" - sure, and this makes sense too. The problem I've been observing, however, is that people get "filtered out" at step 0 and never even start the journey from newcomer to expert. "Essentially, as much as I'm all about hand-holding a newcomer through the process, we need to create the architectures that lets people with no direct relation with Reason community, without the opportunity to assist to a workshop, to know the space of APIs and how to use them." - yet again, I see the point, but one might argue that instead of trying to cram everything into a "template", a better place for learning "the space of APIs and how to use them" would be:
I remember getting started with Reason myself, and I had no issues checking the dog-fetching examples in the now deprecated examples repo - it just seemed like a natural progression after getting going with the basics. As for transitioning from beginner to expert, perhaps we could borrow some ideas from Elm here too. One of the things they have is a gradual move from Browser.sandbox to element, document and eventually to Browser.application (SPA). Perhaps a guide/tutorial how to start from scratch and eventually get to the current "template" would be more approachable? I am open to a possibility of working on such a guide myself if we manage to get a consensus on how to proceed. To sum up - I definitely understand and agree with most of the points you've covered, but my feeling is that what you're describing is more like a collection of good usage patterns/examples, rather than a "starter" or "template". I would be happy to discuss this further via a hangout - it could prove useful for sure. |
There used to be an example repo. It got stale because nobody was maintaining it. As I've mentioned in the blog post, the excessive amount of intro tutorials caused trouble too. We have a dedicated location for most pieces of docs; but that doesn't matter if userland creates new tutorials for every concept every so often. Too many tutorials (and starter template) is a real problem. I've tried the step by step, file-based tutorial using https://github.com/chenglou/intro-to-reason-compilation. I like that format, but it still gets stale. Maybe we can try it here too. I'd love if you can help us spread the message that it's encouraged to delete code. The template is designed to let you delete code. As a matter of fact these are some of the easiest code to delete (which other boilerplate even encourages that?). We can't expect folks to start deleting production code if they didn't learn anywhere to delete code of lesser importance. And finally, two starter boilerplates is already too much. At 3 we'll gonna start seeing tutorials about which boilerplate to choose when. Which happened in the past. We can keep discussing about how to shrink things down, but a boilerplate that doesn't cover much of the RR's critical paths, or without proper design thoughts, will just end up soliciting more of the feedback along the line of "I don't know how to use the API", "what if I don't want webpack", "the template doesn't even have proper design", etc. (Latter of which I care a lot, but that's a longer discussion I'm too drained to start on text). And yeah, please ping me on Discord to set up some time to video chat about this! |
I'd love if you can help us spread the message that it's encouraged to delete code - I could try, but it's a bit tricky, because I don't believe it is a good idea myself 😄 I agree with you that 2 templates is too many. My raw opinion is that it's enough with one "starter" that is almost empty (similar to CRA) + a guide on how to reach an application that covers "much of the RR's critical paths" + make this "final" code available for cloning. Not the other way round (when one would start with a lot of code and have to figure out what to delete without breaking everything). Ok, let's continue on discord/hangouts - thanks! |
This PR adds a new minimal
react-starter
template withwebpack
configuration, discussed in #4000 .I have also added some docs on how to add/edit templates and test them locally, since it might help someone else doing it later.
Let me know if there is anything I can improve!