STstaltz·Nov 25, 2016
Yes, I'm very happy with that code, apart from one thing: how animations are done sometimes with tweens in JS, and sometimes with CSS.
I'm sure it could have been built with less code. In general, the more shortcuts you take and the less abstraction you use, the less amount of code you will have. But also, it's likely that you would mix concerns more easily. So in general, when separating concerns, you end up getting more LOCs. That's what I've perceived in my experience, not a fact that I can prove.
So I do feel like model-view-intent shines here. Model only has state concerns. I was careful in moving away DOM-related code from the model. So theoretically you could reuse this model for React Native or any other UI target. View only displays state in a visual representation, and intent only captures user events and represents them in a fo
Read the rest
rm suitable for the model.
About some TypeScript code, I think you referred to https://github.com/staltz/matrixmultiplication.xyz/blob/mast.... These could have been avoided. The only purpose they serve is to make inference work out for lines like these: https://github.com/staltz/matrixmultiplication.xyz/blob/mast... TypeScript knows that `action` is of type StartMultiplyAction. If we had only done `.filter(ac => ac.type === 'START_MULTIPLY')`, TypeScript couldn't infer anymore. So I understand those isFoo functions are very boilerplatey, but they serve the purpose to provide accurate typings. It's optional and depending how you write TypeScript code, you can use more type casting and more `any`, or you can go down the route of providing accurate types everywhere, which is what I did. This is not at all related to Cycle.js nor MVI.
Feel free to ask more architecture-related questions. I like these. What else feels like "too much code"?