Not sure what Enzyme's plans are, since I know they depend on some React internals.
However, we've worked closely with the React Testing Library maintainers, and that's the solution I'd recommend for React tests going forward. We're fans of RTL because it encourages you to write tests "end-2-end"-like tests that resemble real-world scenarios and are resilient to implementation changes.
That's a shame, because there are plenty of use cases where testing a shallow render makes much more sense than fully rendering the component—for example, when you're wrapping a third-party library and simply need to test that the correct props are being passed, instead of testing the library's functionality.
Sure, but using Enzyme has been easier and far less brittle in my experience by being less reliant on hacky, library-specific mocking techniques. (Then again, I suppose you could argue that Enzyme is itself a giant hack, but it worked very well for me in the past.)
Who are these jerk users? I'm going to give them a noogie!
In all seriousness, I'm sorry you had such a bad experience. That's not what we want the React community to be. Next time, feel free to tag me or someone else on the core team and we'll tell them to cut it out.
We do intend to ship a ES module build of React in the near future. Because that's a breaking change that could require significant changes to existing apps (i.e. to update the imports), we'll likely wait until the next major release cycle.
However, note that tree-shaking probably won't help much in the case of React. React isn't a library of independently useful features; it's a cohesive framework where features work together. We also have a really small API surface area. So there's no much to "shake" apart.
Arguably the main `react` package would benefit slightly from tree shaking, but those exports are already really small. The `react` package doesn't contain that much implementation; it mostly just calls into internal React DOM to schedule updates.
We have a mechanism to handle this exact scenario. We classify certain user input events, like keypresses and clicks, as "discrete" events. Updates that are triggered from discrete event will always be processed sequentially. We don't batch multiple events. Although we do batch multiple setStates within the same event, which is different. "Automatic batching" refers to the updates themselves, not the events.
We call non-discrete events (like mousemove) "continuous", and for those we will batch updates across multiple events.
We've been testing this at Facebook for a while and we think our model is really solid, handling all the common cases and a bunch of edge cases, too. If you try it out and find something unexpected, please let us know and we'll fix it!
I agree the React implementation is very complex, but in a way that's by design: we add features to React when it allows us to move complexity out of our product code and into a framework.
Like, yes, implementing batching in React was complicated, but in exchange the developer doesn't have to think about it anymore. It just works!
We did mention some prior art in the section discussing the new syntax:
> Fragment syntax in JSX was inspired by prior art such as the XMLList() <></> constructor in E4X. Using a pair of empty tags is meant to represent the idea it won’t add an actual element to the DOM.
You're right that we could have referenced document.createDocumentFragment(), too. Perhaps we'll add that to the documentation. Thanks for the suggestion!
Sure, we can call it syntax. Of course, for anyone who already knows what it does, it's just a transform, but the problem with extra syntax is that it makes it harder for newcomers to pick it up.
Taking your example when putting it in front of someone seeing it for the first time:
In: <></>
Out (Newcomer): WTF does that mean? Did someone forget to put something in those tags?
Same newcomer, in a couple of weeks: "Don't know how I lived without it".
I understand your point, but in practice people love tiny affordances like this, especially when they are needed as often as fragments are.
This is a balance, but it's important to consider the needs of power users too. Beginners don't stay beginners forever. We've thought about this for a few months, and decided that adding syntax would be better. I understand some people will always disagree though, and that's fine :-)
Yeah, it seems like the decision to make the fragment a first-class JSX concept has a lot to do with portability between renderers. The post makes it clear you all have given this a lot of thought and care, and I appreciate that (even if it will take me awhile to get used to seeing empty tags, haha).
I'm guessing it's because JSX is XML-like and so parsers may require a single root element for each JSX "document". It's a good question though, hopefully someone from the React team might be able to comment.
It would be, wouldn't it. Silly I didn't realize that right off the bat.
Can't imagine putting forward a proposal that wouldn't in essence be what you're doing, i.e. wrapping in JSX delimiters. Because attempting anything fancier than that would probably have edge cases for days, plenty of material for you to poke holes in.
No problem! And on re-reading my comment, I probably shouldn't have used the word "insidiously", it came off a lot more negative than I intended. Thanks for the quick fix.
I believe the idea is to expose as little of the prioritization details as possible. E.g. updates triggered by a text input's change event will automatically receive higher priority. Or a DOM element with display: none will automatically receive lower priority. Etc.
The proposal doesn't sound like that was what was intended - it seems like it is left to the user to implement the fibers, with the work priority to be set by the user somehow. Indeed, a quick glimpse of the commits of the implementation reveals a priority system of values exposed directly to the user when creating components (see unit tests).
acdlite is correct here -- most users won't need to worry about priorities and it's unclear to what extent we'll even expose them. The unit tests do not describe a public API (and we're not close to settling on one).
Thanks for the clarification! I've been flying 16 hours today (Milan to SF), so I'm sure I didn't grasp the full significance of the concepts in the doc.
However, we've worked closely with the React Testing Library maintainers, and that's the solution I'd recommend for React tests going forward. We're fans of RTL because it encourages you to write tests "end-2-end"-like tests that resemble real-world scenarios and are resilient to implementation changes.