Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversion between JS and clj doesn't preserve key order, messing up this.props.children #6

Open
gaearon opened this issue Jan 4, 2015 · 5 comments

Comments

@gaearon
Copy link

gaearon commented Jan 4, 2015

I can't figure out why this happens.

I copy-pasted third example, but I wanted to play with text inputs. For starters, I tried simplest example possible: I wanted to animate , world away and back inside a <div>.

This is what I did:

var App4 = React.createClass({
  getInitialState: function () {
    return { text: 'Hello' };
  },

  handleClick: function () {
    if (this.state.text === 'Hello') {
      this.setState({ text: 'Hello, world' });
    } else {
      this.setState({ text: 'Hello' });
    }
  },

  render: function() {
    return (
      <div style={{ marginTop: 20 }} onClick={this.handleClick}>
        <Container>
          {this.state.text.split('').map(function (l, i) {
            return <span key={i}>{l}</span>;
          })}
        </Container>
      </div>
    );
  }
});

However, this refused to work with Container: items would animate but children order would get messed up when I click.

I soon realized that this line messes up child order:

var children = M.js_to_clj(/*toObj(*/nextProps.children/*)*/);

(namely, I had to remove toObj call)

Similarly, I had to change the loop in Container#render to enumerate an array instead:

   /*
    for (var key in state.children) {
      if (!state.children.hasOwnProperty(key)) {
        continue;
      }
      var s = {
        top: state.configs[key].top,
        width: state.configs[key].width,
        opacity: state.configs[key].opacity,
        position: 'relative',
        overflow: 'hidden',
        WebkitUserSelect: 'none',
      };
      children.push(
        <span style={s} key={key}>{state.children[key]}</span>
      );
    }
    */

    for (var index in state.children) {
      if (!state.children.hasOwnProperty(index)) {
        continue;
      }

      // Why do I have to do this?
      var key = '.$' + state.children[index].key;

      var s = {
        top: state.configs[key].top,
        width: state.configs[key].width,
        opacity: state.configs[key].opacity,
        position: 'relative',
        overflow: 'hidden',
        WebkitUserSelect: 'none',
      };
      children.push(
        <span style={s} key={key}>{state.children[index]}</span>
      );
    }

Why does this happen when going over characters? It's not like this is too different from your App3 example.

You can play with it in this branch.

@gaearon
Copy link
Author

gaearon commented Jan 4, 2015

screen shot 2015-01-04 at 18 25 44
screen shot 2015-01-04 at 18 25 36

@gaearon
Copy link
Author

gaearon commented Jan 4, 2015

It seems like we're running into an implementation detail of Mori here.

These two are not equivalent:

    console.log(
      toObj(nextProps.children),
      M.clj_to_js(M.js_to_clj(toObj(nextProps.children)))
    );

When converting object back and forth, key order may change—and we currently rely on key order when rebuilding props.children.

This is also visible in third example if you start with too many items:

screen shot 2015-01-04 at 18 32 09

@gaearon gaearon changed the title In a variation of third example, state.children is in messed up order Conversion between JS and clj doesn't preserve key order, messing up this.props.children Jan 4, 2015
gaearon added a commit to gaearon/react-state-stream that referenced this issue Jan 4, 2015
@gaearon
Copy link
Author

gaearon commented Jan 4, 2015

I got a PR for this (#7), basically the fix is to store key-value pairs explicitly so order doesn't get lost.

@chenglou
Copy link
Owner

chenglou commented Jan 4, 2015

Man you're fast lol. Yeah I knew this was the case. I just didn't think someone would play around with this lib so quickly. I actually had some local code to fix this behaviour but it was relatively low-pri. I'll do it when I find the time (slightly busy here)

@gaearon
Copy link
Author

gaearon commented Jan 4, 2015

Yeah sure. I just got super excited about this lib and couldn't wait :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants