rpominov

1. If it works for you just use single container on top of each route, othervise see 2
2. Wrap a view into container whenever necessary, but always pass wrapped component via props:

// pure component's render
<foo>
  <bar>
    {this.props.someWrappedChild}
  </bar>

rpominov

Stateles components

// mark relevant parts of result tree with __tetsId & __testClass
const TestTarget = props => 
  <div>
    <Foo foo={props.foo} __tetsId="foo" />
    <ul>
      <li num={1} __testClass="baz" />
      <li num={2} __testClass="baz" />

rpominov

Just an idea how to do better than https://github.com/mzabriskie/react-draggable

Idea: extract the state — make it controllable.

Instead of this

<Draggable
    axis="x"
 handle=".handle"

rpominov

React-teleports concept

<TeleportManager>
  <Foo>
    <TeleportExit id="abc" />
    <Bar>
      <TeleportEntrance id="abc">
        <Baz />
 

rpominov

/* Will render <Counter/>, a number input, 
 * and a log-output widget with all onChange calls e.g.
 *   > onChange(1)
 *   > onChange(2)
 */
<Demo 
  target={Counter}
  props={{
    count: Demo.props.int.arbitrary
    onChange: Demo.props.callback.log

rpominov

function createStream(executor) {
  return {
    observe(sink) {
      return executor(sink)
    }
  }
}

function map(fn, stream) {
  return createStream(sink => {

rpominov

Promises how I would do them

1. No over polymorphic .then

Four methods instead: .map(a -> b), .mapError(a -> b), .flatMap(a -> Promise), .flatMapError(a -> Promise).

Why?

• more predictable code
• easier to understand what is going on

rpominov

Keybase proof

I hereby claim:

• I am rpominov on github.
• I am rpominov (https://keybase.io/rpominov) on keybase.
• I have a public key whose fingerprint is 9437 BD43 92AE 328C 4E24 29CA DE8A 5DF2 1C0A 2757

To claim this, I am signing this object:

rpominov

const flux = createFlux();

flux.addStore('counter', {
  initial() {
    return 0;
  },
  reducers: {
    add(cur, x) {
      return cur + x;
    },

rpominov

http://www.quirksmode.org/blog/archives/2015/01/the_problem_wit.html
http://www.fse.guru/2-years-with-angular
http://blog.dantup.com/2014/08/you-have-ruined-html/
http://leoasis.github.io/posts/2014/10/28/think-twice-or-thrice-before-using-angular/
http://sixrevisions.com/javascript/why-i-ditched-angular-for-react/
https://medium.com/este-js-framework/whats-wrong-with-angular-js-97b0a787f903

http://www.letscodejavascript.com/v3/blog/2015/01/angular_review
http://www.letscodejavascript.com/v3/blog/2014/09/react_review