Emitting undefined automatically when a component's onion stream is unsubscribed about cycle-onionify HOT 3 OPEN

Hi @ntilwalli

I understand that currently the only way to remove an unused child component's property from the onion state is to have the parent set it's state value to undefined.

Alternatively, the child can also set its own state value to undefined. Either the parent or child have control over that.

But what's puzzling me is to think of a case where a child component disappears but its state property is still present. So far I've been treating undefined setters as the only way of making a component disappear. So it should be an equivalence: "the child component is shown if and only if its corresponding state subtree is not undefined". What does your use case look like?

from cycle-onionify.

Here's one use case I believe (child state gets added to parent and doesn't get removed).

const toggle_visibility$ = DOM.select('.foo').events('click').fold((acc, val) => !val, false)
const child$ = toggle_visibilty$.map(show => {
  if (show) {   // Uses onionify
    return isolate((sources) => {
      return {
        DOM: sources.onion.state$.map(state => div([state.val ? state.val : null])),
        onion: xs.of(state => {
          return {
             val: 'Some value'
          }
        })
      }
    })(sources)
} else {
  return { // return an empty component
     DOM: xs.of(undefined),
     onion: xs.never()
  }
}).remember()

const child_dom$ = child$.map(child => child.DOM).flatten()
const child_onion$ = child$.map(child => child.onion).flatten()

from cycle-onionify.

Okay I understand the use case now.

I'm afraid doing what you asked is not possible, or at least would break other use cases. I can explain how.

First note that the onion sink is for writing state. When that sink is unsubscribed, it means that child component won't anymore write state. But that doesn't mean its state scope should be destroyed. What if the child uses a property on the parent state object which other children will also read? Yes, isolation still plays a role there in order to separate sibling scopes, but onionify supports lenses and this means the child's readable state can be a summary of the entire state object from the parent.

This is why we can't automatically emit an UndefinedReducer when child reducer stream is unsubscribed, because we have no guarantee that the readable state from the child is not also read by others.

Now that I saw your use case, I can recommend a refactor of it. Instead of toggle$ mapped to a component, I recommend clicks on .foo to emit reducer which will toggle the child's substate.

Assuming

type ParentState = {
  // ...
  child?: ChildState,
}

The toggling reducer in the parent could be

toggleReducer$ = click$.mapTo(function toggleReducer(prevState) {
  if (typeof prevState.child === 'undefined') {
    return {...prevState, child: {}};
    // I put {} here, but this can be anything, as long as the child's
    // default/initial reducer will override that with its own definition
    // of child initial state  
  } else {
    return {...prevState, child: undefined}
  }
})

Then you can instantiate the child component once, and statically (not map+flatten dynamically) and it should appear/disappear according to its given state.

from cycle-onionify.