API Design Direction: Overloading vs. Separate Functions
objectliteral opened this issue · comments
Plans for the future include the ability to rename store props to component props (probably via an object {fooInStore: 'fooInComponent'}). I also want, at some point, think about adding functionality reminiscent of Redux' mapStateToProps (although that is a bigger undertaking).
We thus have to either heavily overload the withState function to accommodate for all of these things or add different API functions besides withState that each have a more specific purpose.
Thoughts?
This could mitigate the problems you would face when using fleux with a large application, as prop names will get more specific (and thus probably longer) when a lot of props are needed for the whole application (e.g. {bugReportEmailReceiver: 'receiver'}). So, thumbs up for the general idea.
For the user, overloading withState would be more comfortable, so I would go with that variant. Unless you plan to add even more slightly different versions of withState
It doesn't seem like there is a clear-cut answer here. Overloading is convenient for the user (has to remember fewer API methods) but at some point gets unwieldy - both on the implementation side, as well as for the user (also potentially harder to find mistakes in invoking heavily overloaded functions).
The tradeoff is likely going to have to be decided on a case-to-case basis so there is no point in keeping this issue open.