acdlite

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!

> The Fragment syntax adds some additional magic to JSX (which is rarely a good thing)

In: <></>

Out: <React.Fragment></React.Fragment>

WITCHCRAFT!! SORCERY!!

Teasing aside, I don't get what's magical about this. It's a straightforward transform. You can call that "magic," I'll call it "syntax."

Fixed now! Thanks for the bug report!

Submit a PR :)

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 ultimate goal is web apps with 60 fps gestures and animations.

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.

When you call setState on a component, only that component's subtree is reconciled and re-rendered.

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 :)

The presentation has some really great points; it's a shame that it's wrapped up in so much FUD.

But from what I can tell, it does seem like React is moving in a more reactive direction.

One example: https://github.com/facebook/react/issues/3398 Another (not sure if this counts, but I think it does): https://github.com/reactjs/react-future/blob/master/09%20-%2...

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.

- More declarative.

- Harder to screw up. Even if you know what you're doing, prototypical inheritance involves several steps which can get repetitive.

- Interoperable with non-es6 "classes". It's not like you're losing anything.

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.

This is the pattern that the Flux library I wrote uses: https://github.com/acdlite/flummox/blob/master/docs/api/Flux...

I wrote also wrote a bit about why components are generally preferable to mixins: https://github.com/acdlite/flummox/blob/master/docs/why-flux...

Or instead of a Make-like tool you could just use Make itself :) Works really well.

I went from grunt to gulp because of streams, then I went from gulp to make because of Unix. Takes some getting used to, but I'm very happy with it. Got livereload (hot reload) working and everything, and you can always write a Bash/Node/whatever script and run it from make if you need to.

Example Makefile with Babel, nodemon, mocha, webpack, React, and React Hot Loader: https://github.com/acdlite/flummox-isomorphic-demo/blob/mast...

That's actually the default, but you can specify a different module system if you like. https://babeljs.io/docs/usage/modules/

Nailed it.

Bad abstractions are dangerous. Good abstractions are empowering.

cough React Native cough

Ah, I see. I don't really agree, because I think the enforced unidirectional data flow is one of the best parts of React, but that's certainly a valid point of view.

I just want to emphasize again that Flux is entirely possible without singletons, and works just as well on the server if you create new instances for every request. Flummox does it, Fluxible does it (at least for stores). It's just a shame Facebook pushed singletons and then everyone followed their lead.

Agree that singletons for Flux are bad, but they're totally not necessary (e.g. https://github.com/acdlite/flummox). And if you don't like Flux, don't use it. I don't see how that's can be a demerit against React, since they're completely separate things.

Whipped together a basic one last night: https://github.com/acdlite/flummox-isomorphic-demo

Yep, that's what I was trying to say. The require cache makes the singleton pattern extra alluring, even in cases where you should avoid it.

Thanks! Yeah, I don't get it either. I think esamatti is exactly right: the original Facebook example used singletons and everyone followed their lead.

That, combined with the fact that all CommonJS modules are singletons, anyway.