Component guide - How to create components with reactive attributes in an idiomatic vanjs way

[iongion]

Some help in this regard might be needed.

There is this example that shows a style that is reactive

const dom3 = div(
  {style: {deps: [counter], f: c => `font-size: ${c}em;`}},
  "Text")

• What if one wants to create a custom attribute that is not style but for example data-icon in a fictive Icon component ?
• What if one wants to create a reactive isOpen boolean attribute for a fictive popup / modal / collapsible ?

I am still wrapping my head with the reactivity model to try to get-it, but it is so fun!

An example

export interface ButtonProps<E extends HTMLButtonElement | HTMLAnchorElement | HTMLElement = HTMLButtonElement> extends ActionProps<E> {
  children?: ChildDom[];
  icon?: IconName | Node | [];
  rightIcon?: IconName | Node | [];
  alignText?: Alignment;
  intent?: Intent;
  active?: boolean | State<boolean>;
  fill?: boolean | State<boolean>;
  large?: boolean | State<boolean>;
  loading?: boolean | State<boolean>;
  minimal?: boolean | State<boolean>;
  outlined?: boolean | State<boolean>;
  small?: boolean | State<boolean>;
  type?: "submit" | "reset" | "button";
}

const { button, span } = van.tags;

export const Button = (props: ButtonProps = {}, ...rest: readonly ChildDom[]) => {
  const componentClasses = classNames(
    // default class
    Classes.BUTTON,
    // reactive
    props.active ? Classes.ACTIVE : null,
    props.minimal ? Classes.MINIMAL : null,
    props.outlined ? Classes.OUTLINED : null,
    props.fill ? Classes.FILL : null,
    props.small ? Classes.SMALL : null,
    props.alignText ? AlignmentClassMap[props.alignText] : null,
    props.intent ? IntentClassMap[props.intent] : null
  );
  const createText = () => {
    return props.text ? span({ class: Classes.BUTTON_TEXT }, props.text) : [];
  };
  const createIcon = (icon?: IconName | Node | []) => {
    return icon ? Icon({ icon }) : [];
  };
  return button(
    // attributes
    {
      class: componentClasses,
      onclick: (e: MouseEvent) => {
        if (props?.onClick) {
          props.onClick(e);
        }
      },
    },
    // children
    createIcon(props?.icon),
    ...(props?.children || []).concat(rest),
    createText(),
    createIcon(props.rightIcon)
  );
};
Button.displayName = `${DISPLAYNAME_PREFIX}.Button`;

How can one make reactive componentClasses ?

I've tried this hereunder but because props are either scalar or State<scalar> I can't get it to work unless the user makes all State<scalar>

  const componentClasses = {
    deps: [props.active, props.minimal, props.outlined, props.fill, props.small, props.alignText, props.intent],
    //
    (active, minimal, outlined, fill, small, alignText, intent) => classNames(
      // default class
      Classes.BUTTON,
      // reactive
      active ? Classes.ACTIVE : null,
      minimal ? Classes.MINIMAL : null,
      outlined ? Classes.OUTLINED : null,
      fill ? Classes.FILL : null,
      small ? Classes.SMALL : null,
      alignText ? AlignmentClassMap[props.alignText] : null,
      intent ? IntentClassMap[props.intent] : null
  )
};

[Tao-VanJS]

What if one wants to create a custom attribute that is not style but for example data-icon in a fictive Icon component ?

Custom attributes of native DOM elements are supported in the same way as properties. When the field of props arg doesn't exist as an element property, VanJS will set the prop value as a DOM attribute. This behavior is discussed at https://vanjs.org/advanced#dom-attributes-vs-properties

What if one wants to create a reactive isOpen boolean attribute for a fictive popup / modal / collapsible ?

For custom components (which is just a plain JavaScript function), there is no builtin support for state-derived properties, although you can provide similar support in the implementation of the component function. I have a feeling that for most use cases of custom components, state-derived properties might not be that necessary. Unlike native DOM elements, where some properties need to be provided in a specific way as defined in HTML specification (for instance, style property has to be in the format of font-size: ${c}em;), custom components can define the props in a way to avoid the need of state-derived properties.

That said, if you feel that you have a strong use case where state-derived properties are necessary for custom components, you can let me know. I will be curious to know if there is a straightforward solution to your problem. Meanwhile, the real-world use cases provide great feedback for the evolution of VanJS

[iongion]

Sounds great. In my experiment with blueprint, props can also be Node, hope that will handle this case too and keep reactivity.

I have another learning, while implementing / porting the ProgressBar

See here https://stackblitz.com/edit/vitejs-vite-kc1gr9?file=src%2Fblueprint%2Fcomponents%2FProgressBar.ts

Due to bindings mechanism, I have to duplicate the clamping / percentage, first is for the aria-valuenow attribute and second is for the width of the nested <div> with class PROGRESS_METER - this is really computing twice, which will cost with scale.

In the original typescript/react component, they do it only once in the render function

https://github.com/palantir/blueprint/blob/ffc88eef61d1662bdba1286a2e0fe7d7eb0041c4/packages/core/src/components/progress-bar/progressBar.tsx#L66

Looking for some ideas to avoid that duplication

[Tao-VanJS]

#38 is created to track the implementation of supporting both state and non-state objects in van.bind and state-derived properties.

Regarding the duplication between clamping and percentage, the key missing feature is "derived states". In earlier versions of VanJS, derived states were supported. However, the support was removed due to the issues of GC in very complex bindings. Indeed, implementing a correct GC behavior is extremely difficult (if not impossible) to get it right without significantly increasing the complexity and the size of the framework. So I gave up this feature and introduced onnew event handler in state objects to handle the inter-dependencies between state objects. With onnew we're able to propagate changes between states but users need to be careful about GC, see: https://vanjs.org/advanced#onnew-listeners-are-not-subject-to-gc

Thus for the situation, generally we have 3 options:

1. Accept the duplicate calculation, which is probably okay if the calculation is not part of the performance bottleneck.
2. Use van.bind to bind the entire DOM node, where in the generation function, we can calculate the 2 properties altogether, thus eliminating the duplicate computation. But the down side of this approach is whenever the state gets updated, the DOM node needs to be replaced by a newly generated one, which can impact the performance as well.
3. Use van.bind with stateful binding, this way we can implement a customized binding logic to avoid DOM node being regenerated when property values need to be updated. This approach has the most optimal performance characteristics but needs some special handling in the implementation.

Admittedly, from users' perspective, React offers a more convenient user interface for this specific situation. I totally admitted that for complex UI applications VanJS is not on par with React. I don't position VanJS as React's replacement or competitor. I am rational enough to recognize the fact. VanJS is just a project that is built with only my personal time. There is no point it can compete with React which has hundred-billion-dollar companies like Meta's backing. The purpose of VanJS, is to solve the problem where other mainstream frameworks don't seem quite care to solve, which is:

I know very little about front end programming. I have no comprehensive tools, nor I am familiar with them. How can I build a useful UI app within just a couple hours?

[Tao-VanJS]

@iongion, I just realized a perhaps more effective way to avoid the duplication - using onnew event handler to register derived states. In your example, you can define a derived state percent, whose val property is changed whenever the source state value is changed, with the code like below:

const percent = van.state(0)
value.onnew(v => percent.val = value == null ? undefined : 100 * clamp(value, 0, 1))

One caveat is to avoid generating ProgressBar component many times with the same state object value, because the onnew event handler never gets GC-ed (see this). You can consider to use a new state object for value whenever ProgressBar is regenerated.

[Tao-VanJS]

Hi @iongion,

With the release of VanJS 1.0, we have much better support for derived states.

For the issue being discussed, you can simply write now:

const value = van.state(...)
...

const percent = van.derive(() => value.val == null ? undefined : 100 * clamp(value.val, 0, 1))

van.derive is a powerful API that can enable lots of programming idioms.

Hope it helps :-)

[efpage]

@iongion: I just realized a perhaps more effective way to avoid the duplication - using onnew event handler to register derived states.

States are not changing without reason. There is always an event, that causes a state change. And in VanJS, any state change is directly propagated to all ressources that are bound to a state, which includes the onnew-event. So, onNew works pretty much like a direct event handler.

Using Van-States is just an indirection that may be helpful to organize your code. But in your case it is possibly easier to call the event handler directly. If you want to avoid direct calls, you can add an onNew property to the calling routine like this:

let callerOnNew = null
function caller{
   ... someCode...
  if (callerOnNew) 
     callerOnNew()
}

function myHandler() {
   ...yourHandlerCode...
}
callerOnNew = myHandler  // --> activate the handler