JSON-Based Component Rendering Proof-of-concept

[alexstandiford]

I conceptualized a JSON-based methodology that can render a button, provide it instructions, and also store the data related to the button to use for React-based state changes. While I am not necessarily convinced this is a 1:1 with the fields API, I do think it's along a similar vein, and wanted to share, since I think some of the concepts I've come up with here may apply in what we end up doing.

The key goal of this particular API is to make it possible for a front end interface to be rendered entirely by any backend, provided the front-end knows how to parse the JSON and render the output from it. This decouples the frontend from the actual rendering, which makes it possible to dynamically change the interface from the backend without writing any specific platform code. I think this is a key component of the future of WordPress, since doing it this way would enable any future admin UI to work natively in an iOS application as well as a web application. You would still have two apps, but everything that actually renders the output is based on the JSON, and therefore can be extended easily.

The JSON is broken into 4 parts:

1. stores - This is a collection of datastores that can be accessed by the other components in the JSON.
2. actions - This is a collection of things that can be bound to an event. When these actions are fired, the tasks inside of them are done in the order they're placed, synchronously. Events can break tasks into async blocks, but that's a little beyond the point of this discussion.
3. validationRules - These are a set of "checks" that basically return true or false, and can be used to do things like determine if something should render at all, prevent a form from being submitted, or maybe conditionally disabling a button.
4. components - This is a list of component objects that will be rendered on the page. Each component's props are defined, which can use both validationRules and data from the stores. This also features events, which can be bound to actions.

{
  "stores": [
    {
      "id": "buttonStore",
      "default": {"buttonValue": "Click Me!"}
    }
  ],
  "actions": [
    {
      "id": "handleButtonPush",
      "tasks": [
        {
          "type": "setStore",
          "args": {
            "target": "buttonStore",
            "value": {"buttonValue": "You Clicked On Me!"}
          }
        }
      ]
    }
  ],

  "validationRules": {
    "buttonClicked": {
      "type": "datastoreValidation",
      "conditions": [
        {
          "store": "buttonStore",
          "operand": "!=",
          "key": "buttonValue",
          "value": "You Clicked On Me!"
        }
      ]
    }
  },

  "components": [
    {
      "type": "button",
      "props": {
        "tone": "positive",
        "disabled": {
          "condition": "buttonClicked",
          "true": "",
          "false": "disabled"
        },
        "children": [{"store": "buttonStore", "key": "buttonValue"}]
      },
      "events": {
        "pressed": {
          "validations": [
            "buttonClicked"
          ],
          "actions": [
            [
              "handleButtonPush"
            ]
          ]
        }
      }
    }
  ]
}

There's no shortage of ways this could be handled. I personally built this out using a basic object-based datastore, but we would likely use redux in WordPress to handle the stores, particularly since we're already using that system now anyway.

There's really not much to the actual button component. It basically works with a react hook useDynamicPropAdapter, which just converts the JSON input into the actual props the button should use.

import { useDynamicPropAdapter } from "@siren/hooks";
import { default as Button } from "../Button";
import React from "react";


const DynamicButton = React.forwardRef<HTMLButtonElement>(
    ( props, ref ) => {
        const buttonProps = useDynamicPropAdapter(props, {'pressed': 'onClick'})

        return ( <Button {...buttonProps}/> );
    }
);

export default DynamicButton;

Here's the adapter. It could definitely be done in a neater fashion, and probably should have multiple adapters built into it instead of a single ever-growing monolithic one, but I just wanted to throw something together quickly.

import { useMemo } from 'react';
import useEventStrategy from "./useEventStrategy";
import { useDynamicStore } from "@siren/hooks";
import { useValidationStrategy } from "./index";

interface DynamicProps {
    events?: Record<string, EventConfig>;
    [key: string]: any; // For other standard component props
}

interface EventConfig {
    validations?: string[];
    actions?: string[][];
}

const useDynamicPropAdapter = (props: DynamicProps, mappings: Record<string, string>) => {
    const eventStrategy = useEventStrategy();
    const validationStrategy = useValidationStrategy();
    const dynamicStore = useDynamicStore();

    return useMemo( () => {
        const newProps: Record<string, any> = { ...props };
        delete newProps.events;

        const createEventHandler = (eventConfig: EventConfig) => {
            return async () => {
                let validationsPass = true;

                // Check validations
                if (eventConfig.validations) {
                    validationsPass = eventConfig.validations.every(validationId =>
                        validationStrategy.validate(validationId)
                    );
                }

                // Execute actions
                if (validationsPass && eventConfig.actions) {
                    // Process each group of actions
                    const processActionGroup = async (actionGroup: string[]) => {
                        for (const actionId of actionGroup) {
                            await eventStrategy.broadcast({type: 'dynamicActionTriggered', payload: {actionId}});
                        }
                    };

                    // Run all action groups asynchronously
                    const actionGroupPromises = eventConfig.actions.map(processActionGroup);
                    return Promise.all(actionGroupPromises);
                }else{
                    return Promise.resolve()
                }
            };
        };

        //TODO: UPDATE THIS TO MAP TO THE PROVIDED OBJECT
        Object.entries(props.events || {}).forEach(([jsonEvent, eventConfig]) => {
            const reactEvent = mappings[jsonEvent];
            if (reactEvent) {
                newProps[reactEvent] = createEventHandler(eventConfig);
            }
        });

        // Process conditional props
        Object.entries(newProps).forEach(([key, value]) => {
            if (typeof value === 'object' && value.condition) {
                const conditionResult = validationStrategy.validate(value.condition);
                newProps[key] = conditionResult ? value?.true : value?.false;
            }
        });

        // Process props for dynamic values
        const processDynamicValue = (value: any) => {
            if (value?.store && value?.key) {
                return dynamicStore.getStore(value.store)[value.key];
            }
            return value;
        };

        // Apply processDynamicValue to all props
        Object.entries(newProps).forEach(([key, value]) => {
            if (Array.isArray(value)) {
                newProps[key] = value.map(item => processDynamicValue(item));
            } else {
                newProps[key] = processDynamicValue(value);
            }
        });

        Object.keys(props.events || {}).forEach(jsonEvent => {
            delete newProps[jsonEvent];
        });

        return newProps;
    }, [dynamicStore, mappings, props, validationStrategy, eventStrategy] );
};

export default useDynamicPropAdapter;

[sc0ttkclark]

Looks pretty cool, I think you’re right that the idea that you could edit the JSON/config without having to do a rebuild is intentionally lowering the bar towards maintenance of a project like that.

That validationRules part is very interesting! Most of what we’ve done with Fields API has not had any conditional logic built in and is a pretty cool example of how that might look.