Subscript Functions vs "x"

[ox-harris]

Coming to Subscript Functions from a totally different background? Wondering how patterns compare between Subscript Functions and your framework of choice?

Questions are welcome in the comments! And it's fine to ask in a new topic.

[ox-harris]

In this example, I want to demonstrate a few similarities and some differences between concepts in IRP (Imperative (Procedural) Reactive Programming) as we have with Subscript Functions and FRP (Functional Reactive Programming) as we have with Frameworks like React, Solid JS, and similar.

Let's start by comparing the meaning of the word "function" in both programming paradigms.

• In IRP, Subscript Functions are indeed functions. function** fn() { /* code */ }
• In FRP, we also have reactivity primitives as functions - e.g. effect blocks like useEffect(() => { /* code */ }), createEffect(() => { /* code */ }), etc.

So, it is easy to think function** fn() { /* code */ } === useEffect(() => { /* code */ }). But no!

• One effect block (useEffect(() => { /* code */ }), etc) is like an event listener that gets called independently when a tracked state changes. Multiple effect blocks are often needed to compose a functional reactive program. Below is an example based on Solid JS:

  import { createSignal, createEffect } from "solid-js";
  
  let [ someCondition, setSomeCondition ] = createSignal(true);
  let [ count, setCount ] = createSignal(10);
  let [ countX, setCountX ] = createSignal();
  createEffect(() => setCountX( count() * 2 ));
  
  createEffect(() => console.log( 'top', countX() ));
  
  createEffect(() => {
      if (someCondition()) {
          setCountX( count() * 3 )
      }    
  });
  
  createEffect(() => console.log( 'bottom', countX() ));

  So, above, we have 3 createEffect() functions.

• On the other hand, one Subscript Function (function** fn() { /* code */ }) represents one reactive context for the entire piece of code.

  function** fn() {
      let someCondition = true;
      let count = 10;
      let countX = count * 2;
  
      console.log( 'top', countX );
  
      if (someCondition) {
          countX = count * 3;
      }
  
      console.log( 'bottom', countX );
  }
  fn();

  Now, we have just one context opened for the entire reactive programming. And our imperative code is automatically compiled into almost equivalent pieces of createEffect() blocks under the hood; but here, we call them "contracts", not "effects".

[ox-harris]

Another major differentiating factor is the execution model in each of these paradigms.

• In the FRP code above, the code looks ordered; the three createEffect() blocks look ordered. So, one might expect to see two entries in the console in the following order:

  top 20
  bottom 30

  But it happens that changing countX inside the middle createEffect() block also triggers the top createEffect() block. Then execution reaches the bottom createEffect() block; giving us three entries in the console:

  top 20
  top 30
  bottom 30

  Personally, my procedural brain found this hard to reason about.

• On the contrary, imperative code within Subscript Functions, although reactive, does not change the top-to-bottom execution model. In other words, execution runs from top to bottom. So, expressions below do not trigger expressions above. Thus, it comes out right in the console:

  top 20
  bottom 30

  So, imperative code within Subscript Functions does not just look procedural, it actually runs procedurally! Changes are forward-applied!

[ox-harris]

The fact that Changes are forward-effective can be seen again when we trigger someCondition to change. Let's use a click event to do this:

• For the Solid JS example:

  document.addEventListener('click', () => {
      setSomeCondition( true );
  });

  The console reports:

  top 30
  bottom 30

• For the Subscript Function example:

  document.addEventListener('click', () => {
      someCondition = true; // But this is not actually necessary
      fn.thread( ['someCondition'] ); // This event is what matters
  });

  The console reports:

  bottom 30

  Changing someCondition made the "if" block to reevaluate, and this involved the countX variable. The "update" event for countX finds subsequent dependents of countX, and the bottom console.log() expression runs.

  So, from whatever line in the code an update happens, updates to dependents are forward-applied. The procedural look of your code is thus maintained at runtime!

[ox-harris]

The great thing about Subscript Functions is that it lets us drop a reactive programming context into normal JS code - offering us a block of contiguous lines of code where reactivity is self-managed. Below is a mental model:

Now, being a self-managed "sub-script", code in the main script need not worry what's happening within. But there's a window into the reactive context that allows changes in the parent context to be propagated in to update dependent expressions: the fn.thread() method.

And that's about Subscript Functions!

Now here's an example of a custom element having it's render() method as a Subscript Function.

// Outer dependency
let count = 10;

customElements.define( 'click-counter', class extends HTMLElement {
      
    connectedCallback() {
        // Full rendering at connected time
        // The querySelector() calls below are run
        this.render();

        // Fine-grained rendering at click time
        // The querySelector() calls below don't run again
        this.addEventListener( 'click', () => {
            count ++;
            this.render.thread( [ 'count' ] );
        } );
    }

    **render() {
        let countElement = document.querySelector( '#count' );
        countElement.innerHTML = count;
        
        let doubleCount = count * 2;
        let doubleCountElement = document.querySelector( '#double-count' );
        doubleCountElement.innerHTML = doubleCount;
        
        let quadCount = doubleCount * 2;
        let quadCountElement = document.querySelector( '#quad-count' );
        quadCountElement.innerHTML = quadCount;
    }

} );

Above, render() is called only once. Subsequent updates employ its .thread() method to update just the relevant contracts in the block. Fine-grained reactivity and optimal performance is gained.

[ox-harris]

In Subscript, the idea of automatically observing outer dependencies is intentionally left out of the design; left to other problem domains. (More on this soon.)

But change detection libraries can automate this - in the meantime. An example is the Observer API.