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

Migrating to React 0.14 and simplification #116

Merged
merged 18 commits into from
Oct 7, 2015
Merged

Migrating to React 0.14 and simplification #116

merged 18 commits into from
Oct 7, 2015

Conversation

mikaelbr
Copy link
Member

Great news! The latest React changes plays beautifully with Omniscient.js! By using Reacts stateless functions, Omniscient can be added without changing anything and just work as memoizaltion of your functional views.

Additionally, this transition means there is no difference between non-JSX and JSX. We no longer need to handle JSX explicitly.

This PR does the following:

  • Removes documentation for and implementation of and statics in shouldComponentUpdate. Instead, use a ignore higher order component. There is still support for defining your own isIgnorable but it is undocumented, and deactivated by default.
  • Removes .jsx and .withDefaults({ jsx: true }). No longer needed!
  • Removes omniscient/native and React Native optionalDep. No longer needed with the separation of React and React-dom.

What remains

  • Rewrite and simplify documentation. Do a complete overhaul to show the simplicity behind the architecture (functional UI, one way communication, stateless, optimized through memoization). One can write normal React components and simply wrap in Omniscient component to get improved performance, with almost zero effort!
  • Anything more? This will be a breaking change, so we should think hard about if there are any other changes that makes sense.

@mikaelbr
Copy link
Member Author

There's also this:

Something you want to check out / champion, @torgeir?

@dashed
Copy link
Contributor

dashed commented Sep 20, 2015

@mikaelbr @torgeir Do you have an idea of an idiom to solve #89?

redbadger/immutable-cursor#5 presents some ideas which may be of interest.


Also, one idea I like to throw around is to encourage the practice of not passing cursors to the components. And instead have a reducing function that will resolve cursor props into "immutable" props which will then be passed to the wrapped components.

Something like:

var Greet = component(function (name){
  return React.DOM.div({}, 'Hello from ' + name);
}, {
    propTypes: {
        name: React.PropTypes.string.isRequired,
    },
    assignNewProps({guestCursor}) {
        return {
            name: guestCursor.get('name', '')
        };
    }
});

I found this to relieve the cognitive load of keeping track of cursor state, and ensure invariants (e.g propTypes) are well kept on every component render.

@torgeir
Copy link
Member

torgeir commented Sep 21, 2015

@mikaelbr This looks good! Loving that the path of react is aligning with that of omniscient :)

Additionally, we need a way to handle event handlers - to look into the delegate/delegee-stuff that operates on statics today to keep event handlers up to date even if components don't have their render called (introduced in https://github.com/omniscientjs/omniscient/issues/67)¨

As far as I remember, there's no immediate resolution to #89 (without relying on keypath), as two cursors pointing to the same data in separate structures (keypaths) are not considered equal. Without cursors this behaves pretty much like what you'd expect.

mikaelbr added a commit that referenced this pull request Oct 7, 2015
Migrating to React 0.14 and simplification
@mikaelbr mikaelbr merged commit 8b3783f into master Oct 7, 2015
@mikaelbr mikaelbr deleted the 0.14 branch October 7, 2015 21:16
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 this pull request may close these issues.

3 participants