Future of Alt

[goatslacker]

This is just to openly discuss any ideas on where you'd like to take alt or what you'd like to do with it. Perhaps actionable tasks can come out of this discussion.

[creatorrr]

With React v0.13 the use of ES6 classes will be available. Also, according to facebook/react#1380 mixins will not be supported for ES6 classes like they are today with createClass.

So, keeping those in mind,

1. Are there any plans for supporting alt with ES6 classes once React v0.13 lands (which is coming soon)?
2. Consideration should be made for alternatives to implement the functionality currently offered via mixins.

[goatslacker]

You can already use alt with React.Element in v0.13. It seems like mixins are going to be left to be addressed at the language level, if there's a solution that pops up though alt will pick it up and support it.

It was mentioned that there will be first-class support for flux store subscriptions, that's an interesting development.

[bjyoungblood]

With actions that fetch data asynchronously, it seems to be a pretty common pattern to have associated success and failure actions. It might be worthwhile to explore a way to auto-generate those.

this.generateActions could possibly be modified to support an API similar to Reflux's.

To take this a bit further, I think it's common for an action to create a Promise that calls a corresponding success or failure action with its result. MartyJS achieves this by creating the actions and triggering one of them for you with the result of the promise.

[RnbWd]

Maybe use a mixin pattern like this? https://gist.github.com/sebmarkbage/ef0bf1f338a7182b6775

[creatorrr]

@RnbWd Interesting but how would this work with multiple mixins overriding the same methods?

[creatorrr]

@goatslacker Another question for alt is whether it's better to keep it to a small and extensible core or expand it to provide a decent feature set for developing frontend apps. IMHO, the direction of this conversation will depend on that.

[RnbWd]

@creatorrr having multiple mixins overriding the same methods sounds like a bad idea.. honestly I don't know. Do the current mixins override the same methods? I was just passing along a tweet I saw @gaearon post.

Also, haven't tried out all the new mixins yet, are there conflicts with overriding methods? I'm still experimenting within mixin alternatives.. not sure what the pros and cons are yet.

Edit: wrote the same thing twice :P

[gaearon]

Interesting but how would this work with multiple mixins overriding the same methods?
having multiple mixins overriding the same methods sounds like a bad idea.

In React, mixins currently have "merging" behavior for lifecycle methods (or mixins wouldn't be useful at all). This is implicit and makes mixin-heavy codebase harder to maintain as it grows.

That "higher level components" gist solves this problem by wrapping components. This way you get lifecycle methods called for free by the virtue of wrappers being real components and thus also receiving lifecycle hooks.

I think Flummox chose right approach: components over mixins. See Why Flux Component is better than Flux Mixin. In the recent release, custom rendering was added, I dig this approach:

let BlogPostPage = React.createClass({
  render() {
    <div>
      <SiteNavigation />
      <MainContentArea>
        <FluxComponent
          connectToStores={{
            posts: (store, props) => ({
              post: store.getPost(props.postId),
            })
          }}
          render={props => {
            // render whatever you want
            return <BlogPost {...props} />;
          }}
        />
      </MainContentArea>
      <SiteSidebar />
      <SiteFooter />
    </div>
  }
});

Gives you full control, and no mixins.

[goatslacker]

cc @mattmccray who's exploring components over mixins in alt.

[mattmccray]

Yeah, I've just started working with components vs mixins in a new app I'm working on.

I called mine Controller and it has a few API changes from FluxComponent -- Mainly I don't like that render prop, so I have it applying a context to child components. You can see it here: https://gist.github.com/mattmccray/5f3a8cd7935404830a63

It's likely to evolve, and I welcome feedback. So far it's actually been kinda fun to use. That said, I haven't had to do anything hairy with it yet.

[gaearon]

Just noting that React has its own concept of context so it may be better to avoid naming confusion. In fact, in React 0.14 it will behave exactly the way you might want for Controller.

[mattmccray]

True! I need to change context to a better name. (Update: I changed it to provide)

Yeah, I'm really interested in parent-based contexts. Primarily for form data management with custom fields, but also this kind of use.

However, there's simplicity in passing props. Passing data in a react context is rather obscure... So I'm not sure if a Controller that passes data via a react context is a great idea.

[acdlite]

Yeah, I agree. Context is usually a hack and should be avoided, hence why it's undocumented. Flummox uses it (optionally) to expose the main Flux instance to arbitrarily nested views, but never for passing store state.

[goatslacker]

@creatorrr late answer to one of your questions. I aim to keep alt core small but provide many components, mixins, and utils.