createStore doesn't signal with a class as the store, but everything else works.
If I creatgeStore using a class: letss say a simple class like this one:
class TryMe {
'tryswitch'?: boolean
}
...
const [simpleTest, setSimpleTest] = createStore(new TryMe());
Then accessing and setting via setSimpleTest and simpleTest work fine. But when I set the "tryswitch" value there iss no signal being generated.
So this code:
<div class="field">
<div class="control has-text-left my-5">
<input id="switch" type="checkbox" name="switchExample" class="switch is-rounded"
checked={simpleValue.tryswitch}
onChange={(event) => setSimpleValue("tryswitch", event.currentTarget.checked)}
/>
<label for="switch"><span class="mx-2 has-text-weight-semibold">Switch</span></label>
</div>
</div>
<Show when={simpleValue.tryswitch}>
<SomeComponent.../>
</Show>
So the SomeComponent doesn't dynamically show when I change the myswitch value.
On the other hand if instead of a simple class I use the below then it works:
const [simpleTest, setSimpleTest] = createStore({
myswitch: false
});
Is this to be expected, is it hard to make it work with a class?5 Replies
Small amendment to the above it seems to work fine for 1 level class like above but doesn't seem to work with nested classes.
If you use the below classes:
class SomeThing {
'tryswitch': boolean;
constructor() {
this.tryswitch = false;
}
}
class TryMe {
'thing': SomeThing;
'trysw': boolean;
constructor() {
this.thing = new SomeThing();
this.trysw = false;
}
}
ANd you replace tryswitch with thing.tryswitch in the above it won't work, whereas with trysw it will.
Note that getters and setters of the store continue to work fine, its just that the signal doesn't seem to happen.
I can make a small test project if it helps to reproduce.createStore was created to support reactive data, so classes were never really in scope.
See also https://discord.com/channels/722131463138705510/1080316414310748190Many thanks for pointing me in the right direction @peerreynders . I may have to change my generators to do plain pjo interfaces, but for now I am going to try and work with classes using createMutable
FYI: https://discord.com/channels/722131463138705510/1245832940060147752/1246121125071687718
3. Read/Write segregation—Precise control and predictability make for better systems. We don't need true immutability to enforce unidirectional flow, just the ability to make the conscious decision which consumers may write and which may not.
By adopting RWS (in the Flux sense) it gets a lot easier to keep your reactive graph free of cycles designing the graph as a “tapestry” that starts with setters at the one edge and effects at the opposite with change propagation in between.
People often emphasize that classes can be designed to be immutable but fundamentally classes as a construct were cultivated to manage complexity, internal mutability being the hidden complexity.
Even the fundamental object design
is at odds with RWS as it mandates that accessor and mutator are fundamentally coupled as is the case with most class instances. RWS embraces CQS at the most fundamental level by separating the accessor from the setter; the container tuple is simply a means of delivery to the owner of both. After that point it's the owner's responsibility to liberally share the query (accessor) while judiciously managing access to the command (setter).
MobX already tried reactivity on classes. Solid is about reactive state which can cover a lot of (possibly most) reactive needs. RxJS is about harnessing "reactive (sync/async) transitions" There isn't just one kind of reactivity.
is at odds with RWS as it mandates that accessor and mutator are fundamentally coupled as is the case with most class instances. RWS embraces CQS at the most fundamental level by separating the accessor from the setter; the container tuple is simply a means of delivery to the owner of both. After that point it's the owner's responsibility to liberally share the query (accessor) while judiciously managing access to the command (setter).
MobX already tried reactivity on classes. Solid is about reactive state which can cover a lot of (possibly most) reactive needs. RxJS is about harnessing "reactive (sync/async) transitions" There isn't just one kind of reactivity.
Meta Developers
YouTube
Hacker Way: Rethinking Web App Development at Facebook
Delivering reliable, high-performance web experiences at Facebook's scale has required us to challenge some long-held assumptions about software development. Join us to learn how we abandoned the traditional MVC paradigm in favor of a more functional application architecture.
SolidJS
Solid is a purely reactive library. It was designed from the ground up with a reactive core. It's influenced by reactive principles developed by previous libraries.
Functions are usually “understood” by observing that they are the things in a computational system whose job is to transfer data structures of typeref This is reflected in derived values where a function transforms consumed state to produced state; but it only runs if it itself is being consumed. In that sense there is no place for “methods”, there are just input sites and effect sites, change propagation takes care of the rest. Class code tends to directly govern the control of flow. With a reactive graph the control paths are laid down during graph construction; later during runtime these paths just “react” to changes in state. That is a very different way of partitioning responsibilities.T1into data structure of typeT2. Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage.
Classes can still by occasionally useful in mundane code and even then: Classes are a template for creating objects.