AngularJS still feels nicer until you get into directives.
I think there is still space for one more framework to rule them all.
Care to elaborate?
This seems opposite to how components ought to work.
Each of those become separate components. Can you reuse them, yes but it would be more helpful to keep them in one component.
// global-store.js
const remove = (arr, el) => {
const i = arr.indexOf(el);
if (i < 0) return false;
return !!arr.splice(i, 1);
}
class GlobalStore {
constructor(data){
this.data = data;
this.subs = [];
}
sub(cb){this.subs.push(cb)}
unsub(cb){remove(this.subs, cb)}
notify(newArr){
for (let s of this.subs)
s(newArr);
}
addData(item){
notify(this.data = [...data, item])
}
removeData(item){
if (remove(this.data, item))
notify(this.data = [...this.data])
}
}
// my-component.js
import myStore from "./stores"
class MyComp extends Component {
...
componentDidMount(){
myStore.sub(this._cb = data => {
this.setState({data})
})
}
componentWillUnmount(){
myStore.unsub(this._cb)
}
}
FYI: You can pass a function as a prop in Vue.js too, just like React.
What are your thoughts on https://github.com/hyperapp/hyperapp ?
Closure components let you use closures to hold state, which ends up being a very elegant pattern. In react:
class Square extends React.Component {
constructor(props) {
super(props);
this.state = {
value: null,
};
}
render() {
return (
<button
className="square"
onClick={() => this.setState({value: 'X'})}
>
{this.state.value}
</button>
);
}
}
function Square() {
const state = { value: null };
return {
view() {
return (
m('button.square', {
onclick() { state.value = 'X'; }
}, state.value);
);
}
}
}
People should learn to write apps with the DOM, that's the framework to rule them all and it's already in the browser. There no need for a framework to write apps that follow the unidirectional dataflow principle. That principle just need to be taught, like MVC or SOLID.
I already lived through the home-rolled, pure-js, custom frontend "frameworks" made by each team's resident "smart guy" once. I shudder just thinking about those days.
React/Angular/framework-whatever are glorious angels protecting us from the tyranny of half-baked, poorly thought out approaches to frontend development.
You don't educate developers to good practices just by abstracting the hard things. You don't need to use React/Angular/Whatever to manage state the right way in a front-end application. You don't need a framework to make code maintainable or testable, or you're just saying front-end developers are so incompetent and undisciplined they need a framework. No they don't, just like one doesn't need a framework like Rails or Spring or Django to write a server app.
> React/Angular/framework-whatever are glorious angels protecting us from the tyranny of half-baked, poorly thought out approaches to frontend development.
No they are not, they are making the developer ignorant of the underlying DOM architecture.
Same goes for React without Redux.
The frameworks have a strong architecture the moment you introduce the flux architecture (vuex for vue, redux for react). Writing vue/react code w/o flux is like putting your entire application code into the view layer of an MVC app.
Writing vue/react code w/o flux is like putting your entire application code into the view layer of an MVC app.
You can easily create a model that knows nothing about the view without Vuex/Redux.
Sure, but why not use the standard solution for the ecosystem.
As far as that linked Abramov post, it felt like a hedge to me. Basically he's saying you don't need redux to write a react app, which is a truism, then lists all the reasons why you should use redux.
Redux "code" is a simple library. But if you follow Abramov's architecture opinions that he only implies in the redux guide, you end up with a full highly scalable front-end framework architecture.
Plus vanilla react is non-deterministic with state. Redux solves this problem and that alone is worth the price of entry.