-
-
Notifications
You must be signed in to change notification settings - Fork 15.3k
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
Instead of providing HOCs, provide container components #5
Comments
There are some nice sides to this approach I haven't considered before. I'll re-evaluate and let you know. |
Again, thanks for raising this. I have a proof of concept of such implementation and it solves several other problems in a much more elegant way. 👍 |
Released in 0.3.0 — a complete rewrite of the React part. Counter example now looks like this: import React, { PropTypes } from 'react';
export default class Counter {
static propTypes = {
increment: PropTypes.func.isRequired,
decrement: PropTypes.func.isRequired,
counter: PropTypes.number.isRequired
};
render() {
const { increment, decrement, counter } = this.props;
return (
<p>
Clicked: {counter} times
{' '}
<button onClick={() => increment()}>+</button>
{' '}
<button onClick={() => decrement()}>-</button>
</p>
);
}
} import React, { Component } from 'react';
import { Root, Container } from 'redux';
import { increment, decrement } from './actions/CounterActions';
import counterStore from './stores/counterStore';
import Counter from './Counter';
@Root
export default class App extends Component {
render() {
return (
<Container stores={counterStore}
actions={{ increment, decrement }}>
{props => <Counter {...props} />}
</Container>
);
}
} Thanks a lot again for helping figure this out. |
Glad I helped. The final implementation looks a lot better than my initial examples. Children as function is a clever thing. This can also help a lot when components become stateless functions. Can't wait to play with Thank you for creating this! |
Just a question about the new Root decorator: why it isn't a component too? |
I'm really sad with this change. I always disliked Flummox API because of this... Loosing the ability to enrich 3rd party components without having to create a new component is disappointing. E.g.: inject intl settings into const wrapIntl = observes('intlStore')
export const IntlDate = wrapIntl(FormattedDate) |
You have a lot of freedom to do stuff. This may help you: const container = function(stores, actions, Child) {
return (
<Container stores={stores} actions={actions}>
{props => <Child {...props} />}
</Container>
);
} or return a full component class, you choose. |
Yeah exactly. |
Root could (and probably should) be a component. I just hated two level nesting of functional I think the proper way to go might be to make |
Indeed. I'll ping you with one in a couple hours |
This is out in 0.4.0. Thanks @hugobessaa for the input, @ooflorent for the implementation! |
You guys are blazing fast |
As in the docs, the decorator
@observes
could couple the counter with the counterStore, instead of giving it the freedom from receiving the counter from any data source via props.I like flummox's
FluxComponent
way of doing stuff: your component is pure and a top-level component chooses how to feed it.For the
@performs
decorator we could have an equivalent component that wires an event of a component (e.g.onClick
,onIncrement
) with an action.I think we have much more power using components this way. More testable and reusable.
I'm far from being an expert on decorators and even on Flux, so please show your views and let's discuss this thread 😄
The text was updated successfully, but these errors were encountered: