Fair question ... two reasons.
1) The "redux" portion of this library is actually only about 10 lines of code, namely the "composeMiddlewares" method used in dispatching, and the "dispatch" method itself (which I had to customize anyway to work with setState). The rest of the library is mainly focused on providing targeted versions of what react-redux and redux-actions provide.
2) Each of those libraries have things that aren't needed here (subscribe / unsubscribe for redux, Provider for react-redux, etc.), and so making a highly-targeted version allowed me to keep the footprint small (~3.5kB minified + gzipped instead of ~13kB with the combination of the three libraries).
while i love functional utility libraries like ramda, the goals with this library are a little different because they are react-specific.
first, making your lifecycle and instance methods pure functions which receive the instance means that you can test them without actually creating an instance ... you can pass a mock object with the appropriate values that you know exist because of the contract. this makes testing both simpler and much faster. it also generally means writing simpler code that reads more declaratively.
second, when coupled with the createComponent method, you can build a stateful, lifecycle-aware, ref-capable component from a standard functional component. this allows for easier augmentation of an existing "dumb" component without having to refactor the entire file to use the class infrastructure.
third, if used across the board, it creates a more consistent implementation of React ... smart and dumb components have the same interface, just additional options applied.
the inspiration behind this is a React-like implementation called deku => https://github.com/anthonyshort/deku. it is kind of a dead project now, but i always appreciated the simplicity of the code you would write with it, so i found a way to make a similar interface with React.
The goal here is functional purity, so that all of your instance methods are encapsulated and easily testable. There are usually a decent amount of hoops to jump through if you want to test lifecycle methods, especially ones revolving around updates.
There is also the benefit of code terseness. Example:
function componentDidMount() {
const {getThing, id} = this.props;
getThing(id);
}
vs
const componentDidMount = ({props: {getThing, id}}) => getThing(id);
The latter is much less verbose, while at the same time being self-documenting. In the former case, you need to introspect the function to determine what is being used (a function and id from props), whereas that information is readily available in the function signature in the latter case.
There are many other examples where your mitigating argument can be applied ... for example, recompose lets you add lifecycle methods to functional components, when converting it to a class is "not that hard". This paradigm has helped greatly speed up my velocity, but like anything else, opinion and preference come into play, so YMMV.
Valid question!
The benefit of using a partial application function lies primarily in testability. Under normal circumstances to test the componentDidMount method you would need to use something like enzyme to physically mount the component, wait for the rendering to occur, and then introspect the component instance to determine if the actions you needed to happen actually happened. This is both slow and tedious. By making a higher-order function that receives the instance, you no longer need to do this because you can very easily mock the instance you need and execute componentDidMount as you would a generic utility. It converts lifecycle methods, instance methods, even the render method into pure functions, and that encapsulation allows for much faster and simpler testing.
There are additional benefits, as you can now leverage shorthand arrow syntax for basic transactional methods like updating state (all the examples in the README showcase this), and several of our team members comment about how the clear separation of concerns between business logic and rendering feels more natural (which is why so many people like functional components), but these are bonuses compared to the real benefit of simpler testability.
Can the person who downvoted explain the reason? This is actually facilitating a paradigm we use in a lot of components in our workplace, so if there is an issue or reservation with it then it would be good to know.
No problem, admittedly it is not something that has direct usage in an application or component or anything. It's main purpose is to serve as a helper under-the-hood for other libraries / methods to compose itself on top of.
Lodash has a similar utility (https://lodash.com/docs/4.17.4#toPath) which works to provide an easy way to recursively / iteratively introspect objects deeply. I built pathington because it handles the 95% use-case while remaining tiny, so that I can solve the same problem in other projects with a much smaller footprint.
Or you could specify displayName on RadioButton and check that property instead. This value is not minified and has the added bonus of helping debug in devtools.
This was built as a kind of successor to react-c3js, as billboard.js is the successor to c3.js (upgrade path should have zero friction). I also added a couple of enhancements, and removed the ReactDOM dependency.
The goal here is functional purity, so that all of your instance methods are encapsulated and easily testable. There are usually a decent amount of hoops to jump through if you want to test lifecycle methods, especially ones revolving around updates. There is also the benefit of code terseness. Example: function componentDidMount() { const {getThing, id} = this.props; getThing(id); } vs const componentDidMount = ({props: {getThing, id}}) => getThing(id); The latter is much less verbose, while at the same time being self-documenting. In the former case, you need to introspect the function to determine what is being used (a function and id from props), whereas that information is readily available in the function signature in the latter case. There are many other examples where your mitigating argument can be applied ... for example, recompose lets you add lifecycle methods to functional components, when converting it to a class is "not that hard". This paradigm has helped greatly speed up my velocity, but like anything else, opinion and preference come into play, so YMMV.