saifelse

Article content is using less than 56% of the available width, due to:

    #content-inner { width: 80%; }
    #content-inner #alpha { width: 70%; }

> McDonald’s doesn’t plan to use the individual images by themselves for this reason. “When you present the visuals for the five key nutrients together in full color,” Fairgrieve concludes, “the potentially negative connotations of red fade away.”

Author of the Benchling mixin / blog post, here. Thanks for including the credit and for making this technique more easily usable!

I'm quite happy that this is being utilized by so many people :-)

While it may be optimized, I think the suggestion is that instead of using a hack repeatedly, it is arguably better to be DRY and abstract it away.

Somewhat interestingly before you'd go from getsentry.com --> app.getsentry.com during authentication, whereas now the domain is the same (i.e. sentry.io/welcome --> sentry.io).

I wonder if this simplifies tooling around analytics, since now their logged-out domain matches their logged-in domain.

Author here, interested to hear what other tools/workflows you use for debugging!

Building a fast rich text editor in React is no easy task, and would be at least a series of articles :-P. At Benchling we've built a fairly fast rich text editor in React--but it was a considerable amount of work and still requires quite a bit more work. You may have heard that Atom was originally written in React, but they abandoned it to avoid its overhead[0]

There are open-source projects worth looking at like Ritzy[1] which is quite fast and written in React from what I've read.

As per your specific issue, I've found that using PureRenderMixin with each line of text represented as a component works for hundreds of lines, but this still ends up with performance issues as you scale to thousands of lines. Using a list of one-character components will run into performance issues much sooner as there is per-component overhead.

[0] https://github.com/atom/atom/pull/5624 [1] http://ritzyed.github.io/ritzy/

I'm going to cover this in my next post, but I've found that using PureRenderMixin with fairly large number of items (~100s) works. The non-trivial step is often identifying why your subcomponents are still re-rendering, which I solved by writing a mixin that logs to the console what props/state is deep equal but not shallow equal (i.e. where PureRenderMixin should theoretically work).

But I agree, it's still not perfect. You avoid doing the more expensive virtual DOM comparison, but you still have to iterate over all the items to do the PureRenderMixin checks. And it is still O(n) time, just with a smaller constant.

Another solution is to not actually render all the children, just the ones that are visible on the screen, i.e. using some React implementation of infinite lists (see: https://facebook.github.io/fixed-data-table/ )

Another idea that I've been thinking about is to arbitrarily fragment your list into lists (possibly of fixed size, or a fixed number of fragments). Each fragment gets its own subcomponent, so we can avoid rendering fragments that haven't changed. For example, instead of a list of 100 items, we treat it as 10 lists of 10 items. If we change one item, we end up instantiating 10 components, and then recursing into the single fragment that has changed, instead of over all 100 items.

What you described is the current replacement for auto-bind (that React.createClass used to do for you). The issue arises when you have not just one SubComponent, but n SubComponents that require the parent method bound to the subcomponent's index, e.g. you have a deleteItemAtIndex method, and you only want to expose {deleteItem: deleteItemAtIndex.bind(this, i)} to each child component. ES6 React classes don't have any special way of handling this.

To re-iterate the possible solutions I've considered:

- Don't pass in a bound method; give the component the unbound method and its index and the child component can call it with the index passed in itself. - Generalize this to a re-usable intermediary component that does for you (it does feel a bit dirty) - Write your own bind function that annotates the bound function with original function + params allowing you to do a "deep" equality check, and then use a variant of PureRenderMixin that does this "deep" equality check.

Honestly, all of the solutions feel a bit hacky, but I've gravitated towards the first and second options.

> can you share more details about your UI stack and dev workflows

Our front-end stack was primarily just webpack (no JSX because CoffeeScript's terseness sufficed). We recently started the migration to using Babel with ES6 and JSX because of the linting / tooling / community behind them.

I will be sharing a more in-depth look at my debugging workflow in the next post, so be on the lookout :-)

> Also any recommendations for performant charting/graphing library that plays well with React?

I haven't used many charting / graphing libraries, sorry!

> What do you use for state management?

We were fairly early adopters to React and Flux, so we have our own internal implementation of Flux. I haven't worked too much with the other state management solutions, but many of them seem like good, opinionated architectures.

> Thank you for sharing your experience and tips regarding developing React apps!

No problem :-)

Author here, happy to answer any questions!

More like:

    if(userHasUpdatedPw) { checkPw(hash(pw)) }
    else{ checkPw(hash(assertDoubledAndTakeHalf(pw)))}

Is there a particular reason why Google servers are still accessible from within MIT despite MITnet being down?