5 ms·
How would you compare this to React.js? In particular, how does SwiftUI approach the concepts that Redux solves [EDIT: in other words, state management]?
by sdegutis 7y ago
How would you compare this to React.js? In particular, how does SwiftUI approach the concepts that Redux solves [EDIT: in other words, state management]?
- rat9988 7y agoRedux and react are two different questions.
- sdegutis 7y agoWhen people make alternatives to React, at some point they have to address the concept of state changes and side-effects, building in conveniences for it, or leaving it for third parties to develop this area.
- nickbauman 7y ago... Or use something like Reagent where there is language level support for reactive state management using atoms. https://github.com/reagent-project/reagent https://github.com/reagent-project/reagent
- sdegutis 7y agoThat looks like exactly what SwiftUI is doing.
- ng12 7y agoThis has nothing to do with Redux. Redux is about storing global data, nothing more.
- _bxg1 7y ago@State var model = Themes.listModel I haven't tried it out, but the above looks more like MobX: @observable model = new MyListModel();
- ng12 7y agoI think it's a closer analogue to React.useState.
- _bxg1 7y agouseState is for cobbling together state onto what's supposed to be a pure-function. SwiftUI, like MobX (in its normal usage), is class-based and keeps state in a class member.
- ng12 7y agoWhat's the difference between a class and a function with local state? (Semantics aside, either way this behavior is implemented in React via useState or setState, MobX has nothing to do with it)
- _bxg1 7y agoMobX takes normal data (usually class properties) and makes it observable, via an annotation. That very much appears to be what the @State annotation in the Swift code is doing, though I don't know for sure. setState is a totally special container for data; while it technically lives in a class member (this.state), it can only be modified via setState. It isn't observable, so much as setState just internally triggers a render directly. useState is different because your state lives out somewhere in React's core framework, associated with your function only through a value and a callback. It doesn't live in your function's local scope itself, because it would get lost if it did. It's very weird and funky because the whole point of non-class components is for them to be pure functions which have no state. useState is this shortsighted workaround for that self-imposed limitation. Redux, finally, is different because its new states are determined as a pure function of the current state and some change. It's the polar opposite of MobX's mutable-observables pattern. Neither is strictly better, but they're as different as can be.
- ng12 7y ago@observable/useState/React.Component.state are all conceptually identical, just with varying implementations of the magic. All of them summon an observable value from the void and provide some method of updating said observable. That said, @State seems most identical to useState -- it provides an observed value which you use $/.binding to update. > It's very weird and funky because the whole point of non-class components is for them to be pure functions which have no state. That's a false assumption, that's not the "point" of functional components. Functional components were always pure simply because there was no way to make them stateful. There are distinct benefits for using stateful functional components over classes -- mainly less boilerplate and abstractable/re-usable state functions.
- baby_wipe 7y agohttps://developer.apple.com/documentation/combine https://developer.apple.com/documentation/combine
- seanalltogether 7y agoLooking over the references and docs, this is pretty much the builder pattern to generate the view tree and data binding to update it.