[wish] API calls in component without 'on' prefix
Opened this issue · 4 comments
It feels puzzling to me that API calls done in components have the 'on' prefix (it reads kinda bad).
E.g. (README.md#L40):
onChange(e) { API.text.onChange(e.target.value) } //use the store's API
would be nicer like that:
onChange(e) { API.text.change(e.target.value) } //use the store's API
Out of the box (without createStore filter), store handlers should begin with 'on'. This this kind of imposes the API calls also to begin with 'on'...
(Side note/feedback: The thingy you name API looks to me as an action object (in Redux thinking) -- just that it is fully transparent and that the single actions are "defined" automatically by the store (-to-api hookup)... Isn't it? Why name it API and not "actions" or the like?)
BTW: Great thing! Thanks a lot!
Hey @fvgoto , first - thx.
about the 'on' thing, not sure what's your suggestion - should the default filter function be different? you can still pass an array with all of the store methods that will be exposed as API -
{name: 'text', api: api, actions: ['change', 'otherMethod']} and name the store method accordingly.
about the second concern - I use the name actions for the filter/array of method that the store exposes to api. Also I think API is shorter and convenient and regards a set of action bulks. But I'm open to new ideas (or aliases) if you have some full insight.
you can always do import action from './api' and use it - actions.text.change. Sometimes I'm even doing:
import api from './api';
const TextActions = api.textMy suggestion was to continue to think about defaults... - nothing wrong right now (and yes, a lot can be adapted to custom tastes [you're right, issue title is badly chosen]).
My general feeling is, that 'on'-prefixed functions are usually callbacks. And callback are rarely called manually - in which case it's a little itchy reading (see OP).
But I think I was a little mislead by the code sample in Readme and by my first usage, which was for AJAX-fetching (componentDidMount() { api.foo.onFetchBar(); })... Most usages will maybe be as a kind of event-callback and then, the 'on'-prefix can/will be OK.
On the other hand (just trying to make usage of Cartiv even easier), if we think of API corresponding +- to a Redux' action object, those actions (or better action creators) are usually not named "onSomething"...
Possibility 1:
By default, expose all store methods (except getInitialState, storeDidUpdate, ...) - equivalent to an always-true filter.
I understand that this may not be desirable, because we may want store-private "reduce methods" (I'm e.g. using them for async .then and .fail/.catch handlers)...
Possibility 2:
(Automatically) map api.foo.myaction to store's onMyaction.
But this is less coherent (on the other side, right now, we also need to know that only 'on'-prefixed methods get exposed to API (without custom array/filter)... ).
(Of course, Possibility 0 being nochange and close this issue)
Mmm.. I guess I'll take your advise.
what do you think about Possibility 1 - all except getInitialState, storeDidUpdate, + _underScorePrefixed ?
Finally it's up to you...
Yes, maybe it's better for quick start and out-of-the box working that "all"(*) methods get exposed by default.
*) "all" meaning all user defined methods except the reserved store lifecycle methods (getInitialState, shouldStoreUpdate, storeWillUpdate, storeDidUpdate) and except methods beginning with _, which are commonly considered private.
No change to the way the actions property works.
That would sound great to me and easier to get it right from the start on.
Happy hacking!