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.
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.
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 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!
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!
setState is a public API, usually triggered in response to a user event like a click or an input change event.
State in React is local to a component, but it can be passed down to a component's children in the form of props.
Centralized state can be achieved using a library like Redux, where an individual component subscribes to an external data store's changes. Redux abstracts the details away, but under the hood it's still just setState.
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.
OpenGov | Redwood City, CA | ONSITE
Full-Stack Engineer
We're innovating, solving big challenges and having fun while doing it. As a senior member of OpenGov's engineering team, you will engage in solving technical problems from taming complicated data sets to pushing browsers to their limits with powerful data visualization and analytics.
We're looking for folks with can-do attitudes who go above and beyond. You are a self-starter who can take early ideas and quickly iterate to build prototypes and products. Our ideal back-end engineer has experience delivering high quality, maintainable code to production, implementing both incremental improvements as well as large features and architectural advancements. Our engineering culture is centered around hiring smart talent, building world-class software and we stay humble while driving forward with our audacious mission.
Some of our current project wish list items include
- Migrate financial data towards a columnar store
- Expand our dashboard reporting capabilities
- Self-service tools for customers to get up and running in minutes
- Deeper data integrations with customers
Responsibilities
- Architect and implement software components with order of magnitude scaling in mind
- Build, analyze, and maintain APIs that power many products
- Work with data (lots of it)
- Contribute towards building a great culture in a small team & company
Ideal Candidate Has
- Strong desire to innovate and build world class software that is mission-driven
- 4+ years of experience and a track-record of developing high-quality code, preferably Ruby in a small, agile team
- Experience working with large, distributed systems
- Experience with JS/Node.js, Postgres, Cassandra
- Experience building SaaS software
- BS/MS in Computer Science preferred
- Sound judgment for balancing between idealism and pragmatism
Thanks for the link! Should clarify that Recompose works equally well with stateful components created with either createClass or React.Component. It just happens to be especially useful for stateless functional components :)
I disagree, but I suppose this a matter of preference. For whatever it's worth, the React team did explore using a constraint-solver, but nixed the idea. They explain their reasoning here: https://www.youtube.com/watch?v=7rDsRXj9-cU&t=14m20s
> Flexbox. The authors missed the opportunity of offering a saner API and favored sticking to the official spec instead.
Flexbox is the saner API we've all be waiting for, in my opinion. I'm curious what the author's objections to it are. That's really my problem with the whole piece — statements like this are thrown out there without much justification or explanation.
Like spicyj said, the wrapper components pattern works really well. Some people have started referring to this as a separation between "smart" and "dumb" components. For instance, "smart" components do things like fetch data, then pass the data as props to "dumb" components. It's a cleaner separation of concerns than having a single component do everything via a mixin.
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.