7 ms·

I've spend a lot of time evaluating Angular + Ionic, Vue and React. My goal is to rewrite my webapp as a SPA with complimentary mobile apps. Maximum code sharin

by WA 10y ago

I've spend a lot of time evaluating Angular + Ionic, Vue and React. My goal is to rewrite my webapp as a SPA with complimentary mobile apps. Maximum code sharing would be nice. I'd like to add to the discussion what I learned and also add Vue for comparison. Vue felt less intimidating at first, whereas React seemed to be overly complicated. Truth is, both are actually quite similar. The problem is that every single tutorial out there tells you: "React is only the V in MVC" (and so is Vue) but then goes ahead and implements all business logic in Components. I found it incredibly hard to learn about a sane (SPA?) software architecture. Some people throw in Redux and Vuex, but they actually only manage the state of the application. This is not where business logic goes. Note: I haven't found a proper solution yet. Or let's call it this way: People dump their business logic in components and Redux and that works just fine to some degree, but they actually treat React more than the V in MVC. Just be aware. React isn't that complicated, especially if you start out with functional stateless components, i. e. Components that only have a render function, props and no internal state. This helps to think about where state and logic should go and once you implement your first React components this way, you see that there's hardly any difference between Vue and React. Vue might let you even produce code that is more ugly than what you'd have produced with stateless components in React. The beauty of React is that it forces you to think in a slightly different way. Vue seemed more accessible for a spaghetti code writer like I was (am?), but it wouldn't really challenge me in the same way like React does. Vue made me understand what reactive is all about, React helped me to think about state more clearly, especially if you want to slowly transition to functional programming. Angular is often seen as a full application framework – and to some degree, that's true. But I suspect you'd gain a lot if you actually wrote your core application / business logic as if it wasn't part of Angular to make it more shareable. For example, if you want to go mobile with Angular, you could use Ionic, but it's not 100% compatible both ways and you must think of a way to structure your app so that certain parts (the model) is actually independent from the framework. You could treat Angular more as a View-layer thing, which simply attaches a bunch of observers to your app state, which reduces the need for many APIs Angular offers and also reduces its complexity. The OP wrote about dependency injection, which I found odd as a comparison metric. DI is a design pattern to solve a specific problem and React/Vue simply don't apply to this design pattern. The main advantage of React over Vue and Angular is: React Native. Vue doesn't have anything close to it. Weex might be there one day, but right now, the docs are very incomplete, half in Chinese and I think it lacks a lot of components React Native already has. With Angular, the logical framework to build hybrid apps would be Ionic. Ionic is nice for specific cases: When your app is read-only! This isn't about performance (it's solid on newer devices) – it's forms and input controls. This is where Ionic shows the ugly side of the underlying Webview: Mobile Safari simply sucks for things beyond a simple input field. Want to show a picker for the date that only shows 15 minute intervals? Good luck with that. An input field that allows decimal only? Your best bet is type=tel and neglect the decimal point separator. Or use the rather un-performant and ugly DatePicker that comes with Ionic. But this is a thing where even average users notice a difference to native input controls. If your app is mostly read-only with nothing more than a button and a toggle as input controls, by all means, go with Ionic. Have a form in it? Make a minimal prototype with just this form and see for yourself how it plays out. React is learn once, write everywhere, because you can't really share any component-related code between React and React Native. In React, you use HTML elements, in React Native, you use native elements.

enugu 10y ago
Isnt Redux about using components to dispatch actions, and all the logic happens in the reducers for the store? So, the Model part is not inside the react view components which are just used for display. If you have uncontrolled components(React terminology for forms with extra data not handled by props), then form validation might require some processing in the components.
- WA 10y ago
  Partially, you're right. Some logic happen in reducers, but not all, because they must be pure. For example, you can't call new Date() in a reducer, because it's not pure. Imagine you have a TodoList with Items that have: a priority and a createdDate. TodoList is always sorted by 'priority, created DESC'. There's also an email service that gives you a high-level overview of the TodoList like so: High Prio (3 items) Mid Prio (1 item) Low Prio (0 items) Total: 4 items, last created: 2017-04-07 11:38 This email is sent out whenever a new item is added. So, your business logic is like this: If a user creates a new TodoItem: - You need to get the current date (unpure, so this must come from an action creator [1]) - You must update the "entity" of TodoList and sort and recalculate its summary - This summary must be send out as an email Or to sum it up: You have an action that triggers a bunch of totally unrelated side effects. This has nothing to do with the state of the View, which Redux manages. But it's still important business logic to this app. The question now is: How do you manage that? Because this clearly must be outside of React and Redux. Some people just slap other libraries on top, but I never found a satisfactory explanation on how to implement such workflows "properly". Too many tutorials are way too simple and gloss over these details. [1]: http://stackoverflow.com/a/34135166/ http://stackoverflow.com/a/34135166/
  - BigJono 10y ago
    The common solution seems to be using redux-thunk to shoehorn all of this business logic into the action creators. I think that's an absolutely terrible idea. IMO redux-thunk muddies up the terms "dispatch" and "action creator" and essentially creates a huge noob trap where new programmers don't even know what an action creator is anymore and they use the wrong terminology for everything. Having said that, I think the thunk pattern is a fantastic solution. The two things the business logic functions need to do their job are dispatch, and the state, and the way redux-thunk does it with dependency injection makes your business logic functions very easy to test. If somebody can come up with a solution with the same principle but without the absolutely moronic overloading of terms that people somehow find acceptable about redux-thunk, then they'll be onto a winner.

by WA 10y ago

enugu 10y ago

Isnt Redux about using components to dispatch actions, and all the logic happens in the reducers for the store? So, the Model part is not inside the react view components which are just used for display. If you have uncontrolled components(React terminology for forms with extra data not handled by props), then form validation might require some processing in the components.

WA 10y ago
Partially, you're right. Some logic happen in reducers, but not all, because they must be pure. For example, you can't call new Date() in a reducer, because it's not pure. Imagine you have a TodoList with Items that have: a priority and a createdDate. TodoList is always sorted by 'priority, created DESC'. There's also an email service that gives you a high-level overview of the TodoList like so: High Prio (3 items) Mid Prio (1 item) Low Prio (0 items) Total: 4 items, last created: 2017-04-07 11:38 This email is sent out whenever a new item is added. So, your business logic is like this: If a user creates a new TodoItem: - You need to get the current date (unpure, so this must come from an action creator [1]) - You must update the "entity" of TodoList and sort and recalculate its summary - This summary must be send out as an email Or to sum it up: You have an action that triggers a bunch of totally unrelated side effects. This has nothing to do with the state of the View, which Redux manages. But it's still important business logic to this app. The question now is: How do you manage that? Because this clearly must be outside of React and Redux. Some people just slap other libraries on top, but I never found a satisfactory explanation on how to implement such workflows "properly". Too many tutorials are way too simple and gloss over these details. [1]: http://stackoverflow.com/a/34135166/ http://stackoverflow.com/a/34135166/
- BigJono 10y ago
  The common solution seems to be using redux-thunk to shoehorn all of this business logic into the action creators. I think that's an absolutely terrible idea. IMO redux-thunk muddies up the terms "dispatch" and "action creator" and essentially creates a huge noob trap where new programmers don't even know what an action creator is anymore and they use the wrong terminology for everything. Having said that, I think the thunk pattern is a fantastic solution. The two things the business logic functions need to do their job are dispatch, and the state, and the way redux-thunk does it with dependency injection makes your business logic functions very easy to test. If somebody can come up with a solution with the same principle but without the absolutely moronic overloading of terms that people somehow find acceptable about redux-thunk, then they'll be onto a winner.