[warfangle]

ReactJS + webpack, though I've used Angular and browserify in the past.

1. It's just a component framework. It doesn't do the kitchen sink, like Angular does. A couple hours reading the spec and implementing a small test case gets a seasoned developer up to speed on it. Flux takes a little bit longer to get used to, though, and I'm still not quite sure I'm 'doing it right.'

2. Coupled with webpack and an automated testing toolchain, development speed is quick. Webpack provides hot module reloading - no need to refresh your browser when you change a file. Very fast feedback loop. 3/3.

3. React with Flux provides a pretty strict but flexible guideline for how to build things. Discrete components, actions and data stores all look similar from a structured point of view. This provides a fantastic environment for unit tests. The favored test runner, Jest, provides automocking for dependencies and code coverage analysis. 3/3.

4. Virtual DOM for rendering performance. ES2015-oriented structure. Ease of testing. Enforcement of application structure without being a serious impediment. Warnings against implicit two-way databinding that can lead to disastrous cascading DOM changes. Good browser debug tool. On a purely subjective level, it "feels like the future."

[ronjouch]

> 3. [...] The favored test runner, Jest, provides automocking for dependencies and code coverage analysis. 3/3.

Thanks for sharing! A few questions about Jest:

a. Are you happy with Jest auto-mocking? How do you keep a team from banging its head on this "exotic" behavior? (Typically, devs would be stuck on a test for a few hours, only to notice they failed to unmock something in the chain being tested). Have you tried the alternative of eschewing Jest and doing vanilla Jasmine, including lots of mocks?

b. You mention "code coverage analysis". Is it working now? Last time I used it, it was broken and in need of a dependency (Istanbul) revamp/upgrade.

c. Do you do "semi-end-to-end" DOM tests (i.e. those booting a micro Selenium-like browser/js environment [1] and letting you do DOM assertions like `findRenderedDOMComponentWithClass` and others at [2])? Last time I worked with React, the team initially loved the ability to do those (as an in-between of unit tests & real end-to-end tests) but after adding a bunch of them, tests took 2min to run instead of 2s, and we were considering removing/splitting them.

[1] Don't quote me on that, I have no idea how these environments work but it's certainly not Selenium :P . BTW, can anyone detail the machinery / underlying engine making those work?

[2] https://facebook.github.io/react/docs/test-utils.html

[warfangle]

a. I am. I'm the only one working on this product so far, so I haven't run into the issue of it being exotic. I test my components, actions, data stores, api util, and misc util modules completely separately though. I have run into the issue of "oh, it's failing because that thing that's mocked is returning undefined instead of an empty array", but that just means I need to test for undefined behavior :)

Everything in my ./node_modules is unmocked, though.

On a previous project, we used karma+jasmine and the mocking became extremely cumbersome very quickly. Setup/teardown for a given module was up to 5-10x longer than the actual tests for said module. It might have been an artifact of applying unit tests to a codebase that was never tested properly before (and then not having time to refactor).

b. It 'just worked' for me. I'm happily generating lcov / clover reports with jest 0.4.17 `jest --coverage`. I even have it in my continuous build setup, so my coverage reports update every time I save. There's weirdness where it will report a branch or function as ignored, and I can't find which branch that is ... but I think that may be an ignored/missed function in the transpiled source (I work in ES2015).

c. Yes. And I love them. Default setup is to run these in JSDom (headless). We're considering doing full end-to-end tests with selenium in an e.g. jenkins environment, but haven't come to a decision yet - as much of that testing would be duplicating the already-written component unit tests.

It is slowing down a little bit. My test suite takes 21 seconds to run right now (including coverage analysis), which is pretty slow considering the number of components I have. Some of the async modules run even slower, though - it hasn't been a sticking point so far, but it will be fairly soon. Average test per component is ~3 seconds, with the longest taking 10 seconds. Test suite runtime doesn't grow linearly, though: average component test is 5.34s; average non-component test is 0.8s; total time taken by tests is 63s; actual (perceived) time for the entire test command including webpack build is 21 seconds.

[ronjouch]

b. Glad to learn it works now :)

c. jsdom, yeah, thanks! Maybe you're used to longer tests and are okay with it; I got spoiled by the early test suite of this project running in one or two seconds, which enabled me to tell my editor to automagically run tests at each save and report brokenness (in Atom, with the test-status package [1]). Which is amazing, almost physical, because it lets you feel when you break stuff and when you're back in a stable state. Then we discovered the jsdom tests, and at this point we didn't have any end-to-end Selenium tests, so it sounded like a great first step and we added them, but liiittle by little they started lengthening the tests, to a point where I abandoned my auto-test setup. Maybe this auto-test looks futile to you, to me it's the kind of enabling real-time dev. experience I now want to replicate on all the projects I work on, like react-hot-loader [2].

[1] https://github.com/tombell/test-status

[2] http://gaearon.github.io/react-hot-loader/

[globuous]

The virtual DOM is sick on ReactJS. However, I ran into quite a bit of trouble when I used Semantic UI + Reactjs for implementing a modal window. Because React works with the virtual DOM, you're not supposed to modify the DOM directly or else React loses track of what's going on. So when I implemented my Semantic UI modal, I would get DOM errors and my application would freeze. What would happen is that Semantic UI's modal changes the DOM directly when you open and close the modal (as in, without going through React's virtual DOM), which makes the whole application unusable.

I guess all I'm trying to say is that yes, React's virtual DOM has its pros, but it will occasionally also have cons (like when you use a third party .js that modifies the DOM directly).

I'm new to React though (two weeks). So there may be well known work arounds for this 'problem'. Since I do not know of any, if anyone does, please share ! :)

[warfangle]

There's a react module for modals :) https://github.com/rackt/react-modal

But yeah, in a similar fashion to angular, modifying the DOM outside the 'blessed' render()ing is a pathway to darkness. You can do a bit of fiddling in the lifecycle though - take a look at https://facebook.github.io/react/docs/component-specs.html#u...