DEV Community: 3Shain

On state mutation on changes of state

3Shain — Thu, 31 Mar 2022 08:45:17 +0000

In this post we will investigate a interesting but rarely thought "problem" of reactivity: state mutation inside effect caused by a previous state mutation.

In this post, the usage of word 'state' is in the context of reactivity - capable to raise (side) effects.
e.g. createSignal - createEffect in solidjs, ref - watch in vue, even React Hooks can fall into this category.

How is that a "problem"? Well obviously there is a recursion-like structure or circular definition in that sentence - like state mutation inside effect caused by a previous state mutation inside effect cased by a previous state mutation...... maybe it will eventually stop at some point or never stop. I personally didn't dislike recursions, I want my code to be predictable though. So if I really need a recursion, I will try to make it as local as possible (or convert to an iteration). However, reactivity inevitably inverts your flow of control. You are asked to set the (source) state and never care what's going to happen (the merit from Separation of Concern), so you are not sure about whether the current mutation will cause another state be mutated, unless - state mutation inside effect is completely forbidden.

How is that possible? I rephrase the question - Is there any functionality that is only achievable by state mutation inside effect?

My answer is no, if you don't mean to construct a recursion. The secret is the implicit dependency and circular reference possibly caused by that implicit dependency. The mutated state in effect is implicitly depending on the state(s) raising that effect, that's intuitive. And if the latter is already explicitly depending on the former, there is a circular dependency constructed. If the recursion never converges , sometimes the reactivity implementation will be able to identify this, but that's just better than getting stackoverflow or infinite loop if the implementation "smartly" utilises the eventloop. Actually some recursion can be proved to converge but most of time you get a convergent recursion accidentally to work, and it is like a landmine that is ready to f-word up everything when you start refactoring (or you cordon off code "LEGACY CODE, IT'S WORKING, DO NOT TOUCH"). Anyway you are not advised to implement recursion based on reactivity (hard to maintain because the control is inverted), and every-time you construct a recursion is by accident. So state mutation could be simply banned for recursion construction.

But what about those non-recursion cases? Since not all mutations will form a circular dependency. Well most of reactivity implementations provide a functionality to declare a state derivation (like createMemo in solidjs), that's an obvious solution if a state unconditionally depends on another one. As for conditional derivation, just one more thing, the previous value (which might be provided already in the API, or store the latest state into somewhere non-reactive (e.g. useRef of react) when effect triggered), so if the condition is false, just return the previous value. In conclusion we are converting implicit dependency into explicit one.

I'm just about to say you don't need state mutation inside effect.

But I soon come up with a made-up use case: there are state A,B,C and two effects mutating C triggered by corresponding changes of A,B. It's neither a case of circular dependency nor solvable by methods mentioned above. So far I think this is an anti-pattern, as the concern of control flow is leaked into reactivity - what if A, B changed at the same time, the execution order of effects does matter, while a reactivity implementation does not necessarily offer guarantees.

What's your opinion? Feel free to talk about in comments.

On Front-end Dependency Injection

3Shain — Sat, 26 Mar 2022 11:18:13 +0000

Just recently I had a good conversation with @samwightt about the design of Context (not limited to react but as a general Dependency Injection mechanism). Several conclusions are made and some problems (objectively) come to light. So I wrote this memo.

Context (DI) compares to Props

Related: React Context for Dependency Injection Not State Management (testdouble.com)

Both of them pass information down (from parent to children) so they seem to be comparable. A good starting point is trying to answer the question: what will happen if there is only props/context available.

If only props available, it's easy to get "props drilling" if the children requiring information is 'far away' from the parent providing such information.
- To solve props drilling, we should try not encapsulate subcomponents as much as possible but that's not ideal (as Separation of Concern) and sometimes subcomponents need to manage their own local state.
If only context available, the View (template) is hard to be represented.

Seems being without context is acceptable and context is more likely a complement to props.

But that's not a satisfying answer to me. I have a more radical statement: Props for View, Context for Model. That means

Props are accessed and should be only accessed in template
Model is only accessible via Context (Dependency Injection)

The reason why this is not obvious (at least in React) is that React Context are not designed for passing frequently changed state. But if the state is a reference-stable reactive container (that you can subscribe to get the value changes) then it becomes applicable (that's exactly how Redux works in React).

By locking props in view, props drilling will be automatically prevented from you because you are limited to abuse props (grabbing everything from props). The Model and View are decoupled, and Context(DI) is the only bridge connecting up them.

There is a better interpretation: State drive view (as side effect) and for children components props can drive view because props are delegate of state from parent (props as actual argument). Also for parent components props are delegate of children's side effect (of view) (props as formal parameter)

Also this implies the component should be either fully controlled or fully uncontrolled. Not possible to mutate internal state on changes of props.

But I found an exception: list rendering of components which have their own model. This kind of component will probably need to read a constant prop which identify the identity of current model (not to be confused with key but they probably get the same value). That's the only case I found the model has to read props. To solve it, render list with pure component only (but it might be not always applicable)

DI introduce coupling and it doesn't matter

Although I don't see how DI introduce coupling, while someone argues that the component consuming data from Context is coupled with the corresponding provider. Are they coupled? Yes and No?! They are coupled because the business requires them to be coupled. They are not coupled because DI are designed to decouple things. Are they talking about the same coupling?...

A not so appropriate metaphor: you have legal relationships with your family members, is that kind of coupling? (no pun)

One thing objectively obvious is that, a component needs some information, no matter how it's delivered. Some need very few (like UI controls) and some requires more contexts especially those related to your business. It's also worth noting that, we divide components into smaller components (Separation of Concern applied?), by simply the visual layout but not the information required. Now you heavily rely on props and think it's explicit and low-coupling (just provide props to use the component, very great reusability!) but now every other components using it but can't provide all of required props will simply throw these to where they are used, and then the same pattern will spread like a virus (props drilling, exactly). That means some components declare a prop not because they need it but their children in template need it. The conclusion is either these component are actually coupled via prop definitions, or The Principle of Least Privilege is violated (you know something you don't need to know).

And a more interesting conclusion come out: not all the components have the same reusability (not a binary 'reusable vs non-reusable', but a possibility of being reused), no matter how pure it is or not, a <Button> tends to be reused more than <GoodItemDetail> because the latter need more contexts.

Just grab from environment

Is that hard to declare a variable at top level and directly import it from components? Yes sometime it works. It's also known as Singleton and if you think your application is a singleton, just go for it. I don't think so though.

The design of API and Hidden Dependency

@samwightt points out a weakness of current React Context API design: you don't know which contexts the component depends on, from the type definition. And I see some down side of flexibility of useContext hooks and the Hooks design itself - too flexible to be abused.

He compared Angular which has built-in DI and forces dependencies to be declared in constructor. One thing obvious is that a Angular service is more easy to test than a custom React Hook which uses context, because for the former you can just provide some Mock/Double/Spy objects (without enabling DI mechanism), But for the latter, firstly you have no idea what the custom hook depend on, secondly the provided context is probably a internal thing encapsulated by third party that you shouldn't directly rely on (like useXXXQuery grabbing a cache management implementation that doesn't exposed as a public API), so you must build a mini application with least working requirement to test a single hook. The first issue could be solved by generators - collecting yielded type you will be able to get a union type of all dependencies. But the second point so far I think it's really unbeatable...... I understand why he thought the React Context is magical.

Being magical is not necessary a bad thing but I can't help trying to think a more explicit design of API, and how it would impact the current mental modal. I really love the current one but it could be improved further. I'm still investigating into this.

To be continue

Promise Cancellation & semantic behind it

3Shain — Mon, 26 Jul 2021 10:23:43 +0000

TL;DR: We do not cancel Promise but operations. Cancellation is orthogonal to the abstraction of Promise. They have different concerns.

Many people have asked: I want a Promise with .cancel() method!

Okey. Let's assume we have one.

const promise = fetch('https://somedata.com').then(x=>x.json());

//... at some point
promise.cancel();

To not violate the original Promise/A+ spec, when it's cancelled (and in PENDING status), reject with an error (may name it CancelledError)

And here's the problem: When .cancel() applied, which promise on the chain is really cancelled?

Top(then "downstream" get notified by catching CancelledError and re-throwing it)

But what if a part of Promises on the chain have resolved? A settled Promise can't modify its state, therefore it can't "notify" its "downstream" again.
If "upstream" is PENDING, what about other "downstream"s?
```
const root = fetch('https://somedata.com');
const promise1 = root.then(x=>x.json());
const promise2 = root.then(x=>x.string());
// ...at some point, root is PENDING
promise1.cancel(); // what about promise2?
```
Current (but don't care about "upstream")

Hmmm, it is .ignore() rather than .cancel(). Not really what we expected.
Current (and cancel "upstream", if possible, i.e. no other "downstream" waiting for a value)

This intuitively makes better sense. But things get really complicated. This is to say explicit dependencies between CancellablePromise need to be managed.....

Actually the two made-up terms "upstream" and "downstream" do not exist in Promise/A+ spec at all. A Promise has no clue how it will be fulfilled/rejected.

Maybe RxJS has done this job.

Seems there is no natural behavior and clear semantic of Promise cancellation. Is cancellable Promise just a wrong abstraction?
Think about the question again. Is it the Promise we want to cancel?

IMO we want to cancel should be the operation.

Recall the definition of Promise: A promise represents the eventual result of an asynchronous operation. It promises you there will be a value or error (that's why it is called Promise). While when we talk about a cancellation, we often mean to abort the procedure and if necessary dispose related resources (to prevent memory leak). To strictly speak cancellation is orthogonal to the abstraction of Promise. They have different concerns.

So we need something else to explicitly manage cancellation, e.g. AbortController

// an example of aborting ongoing fetch
const controller = new AbortController();
const signal = controller.signal;

fetch('https://example.com', { signal });

// ...at some point
controller.abort();

I know it's verbose, but to manage cancellation separately makes the most sense.

await Promise !== coroutine

3Shain — Sun, 25 Jul 2021 11:10:59 +0000

Yeah this is a sister post of Inversion of Inversion of Control. In that post I've illustrated the idea of coroutine (which invert the inverted control back) implemented by async/await. However, here I'd like to investigate it in depth and conclude that async/await syntax is not strictly coroutine.

Let's see an example.

Ingvar Stepanyan

@rreverser

Before:
(function animate() {
...
requestAnimationFrame(animate);
})();

Nowadays:
const nextFrame = () => new Promise(resolve => requestAnimationFrame(resolve));

(async function animate() {
while (true) {
...
await nextFrame();
}
})();

10:56 AM - 21 Jul 2021

The code:

const nextFrame = () => 
new Promise(resolve => requestAnimationFrame(resolve));

(async function animate() {
  while (true) {
    // ... maybe we should add an exit/break condition
    // lovely in-control-render-loop
    await nextFrame();
  }
})();

But it has a problem: Your code is not executed in rAF callback synchronously but a micro-task callback. So intuitively you get zero benefit from using rAF.

Ironically you might never notice this as some implementations do cover the case. See Timing of microtask triggered from requestAnimationFrame

It's due to the spec of Promise: always trigger a micro-task. But in a real coroutine, the control is expected to be resumed at a specific point, synchronously. The rAF is such an example, and some libraries/frameworks would use black magic side-effect-ish global variable to store context informations in a synchronous procedure. (And luckily JavaScript is single-threaded, otherwise...). Anyway we need control back immediately, not delegated by a micro-task.

Someone may ask: why a Promise must be asynchronous? Can't we have a synchronous Promise? (off-topic: the executor function in Promise constructor is executed synchronously.) The answer is: it could be but it shouldn't be. Having an asynchronous model simplifies the design, as Promise represents the eventual result of an asynchronous operation. For a Promise we only concern the value (and/or reason for no value). So a Promise just tell you "I'll eventually give you a value but not sure about when it's available (and doesn't necessarily to be in a micro-task.)". Even a fulfilled/rejected Promise notifies the value asynchronously, to make the design consistent. So you know the callback in .then is always deferred. Otherwise,

// not runnable code, for illustration purpose
aMaybeSyncPromise.then((x)=>{
  // assume an error is thrown in callback
  throw 'Oops!!';
  // or access a closure variable
  doSomething(y); // 'y' is undefined if sync
});
// ... original flow of control
let y;
// ...

a sync and async callback give different behavior.

So let's go back to coroutine. Can we have a proper coroutine in JavaScript? Of course, by Generator. You can implement your own scheduler, and decide when to return the control back. (But it doesn't seem to be easy as it is described 😅. I planned to list some implementations here but none of them is Promise-free). I'll continue on this topic.

Inversion of Inversion of Control

3Shain — Sat, 24 Jul 2021 15:32:08 +0000

Inversion of Control is a common phenomenon that you come across when extending frameworks. Indeed it's often seen as a defining characteristic of a framework. -- Martin Fowler

The key part is the 'framework' calls you rather than you calling the 'framework'. The 'framework' doesn't need to be any specific thing. An operating system, a language runtime, or an application framework could be that 'framework'. As you register an event handler (no matter explicit .addEventHander or implicit lifecycle), you are already using IoC.

But is IoC always good? Or we should say, is IoC always what we desired?

IMO most of IoC is not intended (DI is the one I think of so far), but the control is by nature inverted, especially in human-computer interaction programming, because this is how the computer works: it is the user controls. If user doesn't input then the program just keeps idling.

# The example provided in the blog above 
puts 'What is your name?'
name = gets
process_name(name)
puts 'What is your quest?'
quest = gets
process_quest(quest)

Then here comes a question: why does command line enquiry seem to keep the control? Isn't the thread blocking and waiting for a signal as well? That is true and in fact the computer is in certain degree event-driven, in form of interruptions. However, conceptually it is in control because it's an imperative process: statements executed in order. There is a clear flow of control.

And I think sometimes we need our control back. Like when there are callback hells. And luckily coroutine(async/await) is to rescue.

// in control

async function foo() {
  const x = await fetch('http://bar.com/');
  //...
}

// control inverted

function foo() {
  fetch('http://bar.com/').then(x=>{
    //...
  })
  //...
  // we get two flows of control now?
}

Maybe this example is so simple that you don't see any difference :/. So let's see another example: you are going to manage a WebSocket connection and it has some rules:

when connected, server sends you 'LOGIN' and you should reply 'LOGIN:<auth token>' and finally when server replies 'VERIFIED' the connection is successful.
whenever server sends 'PING', client must reply 'PONG' (in 30 seconds maybe) otherwise connection will be closed.

Normally WebSocket is event-driven and we might write a version like this

const socket = new WebSocket('foo.bar');
let isVerified = false;
socket.onopen = ()=> {
  socket.onmessage = ({data}) => {
    if(data=='LOGIN') {
      socket.send('LOGIN:'+authToken);
    }
    else if(data=='VERIFIED') {
      isVerified = true;
    }
    else if(data=='PING') {
      socket.send('PONG')
    } else {
      // process the data
    }
  }
}

This code might work. But there are edge cases like what if server doesn't reply the expected message? To add more state (isLogined, isSuccessful) is a solution but it's redundant (you might check current state whenever callback executed), and not easily-extendable if there are more steps.

However if the control is inverted, the logic will become much more natural. Imagine we have a IoCWebSocket and it provides a modified WebSocket with extra methods:

// resolve when it's open
async ready():Promise<void>;

// resolve when there is a incoming message
// reject when websocket error
async read():Promise<string>;

Then the logic becomes:

const socket = new IoCWebSocket('foo.bar');
// ...
// assume inside an `async` function body
await socket.ready();
let next = await socket.read();
if(next!='LOGIN') {
  throw Error('Unexpected reply '+next);
}
socket.send('LOGIN:'+authToken);
next = await socket.read();
if(next!='VERIFIED') {
  throw Error('Unexpected reply '+next)
}
while(true) {
  try {
    next = await socket.read();
    if(next=='PING') {
      socket.send('PONG')
    }
    else {
      // process the data
    }
  }
  catch {
    // may catch error and re-throw if it's not due to connection closed.
    break;
  }
}

Do you notice the order (which is an implicit rule) is naturally guaranteed?

And we may have many analogous situations like drag-n-drop, step-by-step enquiry, cheat codes, (stateful) animations and interactions(hold to activate/n-times click)......they are procedures with extra (temporary) context informations, they're designed to have an order, they could own their own flow of control.

Bonus: Co-routines as an alternative to state machines

This post is about 'what'. As for 'how', I'm still investigating the most optimal solutions. Promise and async/await are fine in most cases. Sister post: Promise!==coroutine