Closed dalgard closed 7 years ago
I always found those boilerplates way too "blackbox". For me I prefer full control over the code and boilerplate. Maybe we could have examples for both?
What you're saying sounds exactly like my argument? The run
function is a black box, which takes away my control over the code.
It's not a difficult task to unravel your code, it's just that one would expect for users of redux-elm
to be very familiar with the standard boilerplate for React + Redux projects – and not with your custom implementation, which consequently introduces some cognitive overhead that ought to have been avoided.
It makes me hesitant to use the redux-elm
example/tutorial for new developers – they already have to deal with understanding basic boilerplate without the custom run
stuff on top, something which I have seen fail in a real situation. "What about all the stuff I've already learned?" "Well, you see, this developer prefers to hide all that behind a custom API. We don't write it like that, though, because we need ..." Etc.
What you're saying sounds exactly like my argument? The run function is a black box, which takes away my control over the code.
Oh yeah sure, my point was that this boilerplate should be very minimalistic so that everybody can understand what's going on under the hood. Maybe we could document the function better.
Definitely. Less is more.
Closing, there's no additional boilerplate need. Redux-elm aka. prism is now just a set of helpers.
Trying to hide boilerplate code behind a custom
run
function in the examples does more harm than good, in my opinion.It makes everything less easy to understand when one is used to reading other examples, and disentangling the
run
pattern in order to incorporateredux-elm
into a more customized setup is a bit of a nuisance.I propose that the examples be changed to standard React + Redux boilerplate.