DEV Community: chris-czopp

How I generate my UI tests

chris-czopp — Tue, 27 Sep 2022 14:33:31 +0000

This article is intended for Solidjs but it should be also useful for React or Preact developers too.

Imagine you're developing dev.to and it has been written in one of the frameworks above. Go to your Chrome DevTools console. Type these two commands:

$str.describe = 'dev.to'
$str.it = 'should render logo'

Then, select Devto's logo with the element inspector. You'll be prompted with:

can be selected by:
screen.getByAltText("DEV Community \uD83D\uDC69\u200D\uD83D\uDCBB\uD83D\uDC68\u200D\uD83D\uDCBB")

Now type:

$str.expect.toBeInTheDocument = true
$str.seeResult

A code editor will show up with this:

import { describe, expect, test as it, vi } from 'vitest'
import { fireEvent, render, screen, waitFor } from 'solid-testing-library'
import { getRequestSpy } from 'rootPath/setupVitest'
import { SomeComponent } from './some-component'

describe('dev.to', () => {
  const waitForInitialRequests = async () => {}

  it('should render logo', async () => {
    const initialProps = {}
    const { unmount } = render(() => <SomeComponent {...initialProps} />)

    await waitForInitialRequests()
    expect(
      screen.getByAltText('DEV Community \uD83D\uDC69\u200D\uD83D\uDCBB\uD83D\uDC68\u200D\uD83D\uDCBB')
    ).toBeInTheDocument()
    unmount()
  })
})

Copy-paste the test to your IDE and job done!

OK... It isn't a complete story as Chrome DevTools doesn't magically generate tests. However, with this open source extension: Solid Test Recorder this and more is possible!

In a nutshell, this bad boy extension:

Generates UI tests which relay on vitest and msw which follow solidjs guidelines.
Uses a combination of Chrome DevTools element inspector and console which gives great recording control e.g. terminal-like auto-completion.
Auto-generates the most specific selector for inspected element.
Records network requests and generates mocks and spies for them.

And here is a list of available commands:


Configuration:
`$str.config.codeTemplates`	allows to edit the code template used when generation test file
`$str.config.excludedRequests`	allows to specify list of URLs to ignore when capturing requests
Testing:
`$str.describe`	creates a new test file with a given description
`$str.it`	creates a new test case with a given description
`$str.expect.*`	adds a new asser on a currently selected element
`$str.capture.*`	starts event capturing i.e. auto-generation user events and subsequent requests
`$str.stopCapturing`	stops event capturing
`$str.seeResult`	opens editor with a generated test file and request mock
`$str.editTest`	allows to reposition or remove test cases and test steps and setting their active cursors
Changing current test file/case:
`$str.use.file`	allows to switch to a given test file
`$str.use.case`	allows to switch to a given test case
Controlling editor:
`$str.applyChanges`	saves changes and closes editor(s)
`$str.closeEditor`	discards any changes and closes editor(s)
Data collections:
`$str.$requests`	captured HTTP requests
`$str.$files`	test files
`$str.$cases`	test cases

Dangerous: $str.clear - removes all the test data

More info in the repo

Enjoy not writing but rather generating your test!

Github stars are much appreciated. 😃

What is your testing approach when working on fast-pace projects?

chris-czopp — Thu, 30 Dec 2021 14:49:58 +0000

Hey guys, I'm wondering how you tackle testing React-based apps. Particularly, I'd like to hear your thoughts about testing rapidly changing products like MVPs.

For a long time I was a big fan of e2e tests. However, many of my past teams struggled setting them up or/and were underestimating their value. Instead, the most common way of testing I observed is unit (I suppose) testing with jest + testing library + axios-mock-adapter (or some other request mocking libs). And here is my inner struggle: in my opinion, very granular unit testing on a MVP isn't the most efficient as often its implementation radically changes. I believe the main purpose of tests on MVP is to lock the current state of UI so the future implementation changes don't break what's been already working. Of course, one will argue that the more tests the better, but the reality is that we need to choose what will work best in a given time-frame (often very limited). Therefore, I worked out my own pattern which is a sort of hybrid:

I test entire pages (mocking routing)
I mock auth-related action(s)
I mock actions which manipulate URL
I even mock Web Workers if necessary
I mock all AJAX requests with axios-mock-adapter in a way which lets me wait for those calls (a combination of spies and waitFor)
My tests are driven by AJAX calls i.e. it's AJAX calls which indicate when certain interaction has been completed
I often use snapshots and treat them carefully when they fail

See this stripped-out real world example:

import React from 'react';
import { ExamplePage } from '../pages';
import { screen, waitFor, fireEvent } from '@testing-library/react';
import axios from 'axios';
import MockAdapter from 'axios-mock-adapter';
import mocks from '../mocks/someCollectionEdit.json';
import renderPage from './helpers/renderPage';

const API_BASE_URL = '/api';

jest.mock('../actions/getters/user.ts', () => {
  const actions = jest.requireActual('../actions/getters/user.ts');

  actions.authenticateUser = jest.fn();

  return actions;
});

jest.mock('../workers/someWorker/someWorker.client.ts');
jest.mock('../actions/setters/url.ts');

describe('render example page', () => {
  let mock;

  const mockRequests = () => {
    // used by waitFor() in tests
    const spies = {
      [`${API_BASE_URL}/user`]: jest.fn(),
      [`${API_BASE_URL}/organizations`]: jest.fn(),
      [`${API_BASE_URL}/some-collection/example-id?someFilter=filter1&organizationId=2`]: jest.fn(),
      [`${API_BASE_URL}/some-filters/example-id`]: jest.fn(),
      [`${API_BASE_URL}/some-collection/details/example-id`]: jest.fn(),
      // ...
    };

    // mocking calls which may include query strings
    ((url) =>
      mock.onGet(url).reply((config) => {
        process.nextTick(() => spies[config.url]());
        return [200, mocks[config.url]];
      }))(new RegExp(`${API_BASE_URL}/user$`));
    ((url) =>
      mock.onGet(url).reply((config) => {
        process.nextTick(() => spies[config.url]());
        return [200, mocks[config.url]];
      }))(new RegExp(`${API_BASE_URL}/organizations$`));
    ((url) =>
      mock.onGet(url).reply((config) => {
        process.nextTick(() => spies[config.url]());
        return [200, mocks[config.url]];
      }))(
      new RegExp(
        `${API_BASE_URL}/some-collection/example-id\\?.*`,
      ),
    );
    ((url) =>
      mock.onGet(url).reply((config) => {
        process.nextTick(() => spies[config.url]());
        return [200, mocks[config.url]];
      }))(
      new RegExp(
        `${API_BASE_URL}/some-filters/example-id$`,
      ),
    );
    ((url) =>
      mock.onPost(url).reply((config) => {
        process.nextTick(() => spies[config.url]());
        return [200, mocks[config.url]];
      }))(
      new RegExp(
        `${API_BASE_URL}/some-collection/example-id/data-draft$`,
      ),
    );
    ((url) =>
      mock.onPut(url).reply((config) => {
        process.nextTick(() => spies[config.url](), 0);
        return [200, mocks[config.url]];
      }))(
      new RegExp(
        `${API_BASE_URL}/some-collection/example-id/data$`,
      ),
    );
    // ...

    return spies;
  };

  beforeAll(() => {
    mock = new MockAdapter(axios);
  });

  afterEach(() => {
    mock.reset();
  });

  it('should edit some form with a confirmation modal', async () => {
    const spies = mockRequests();

    renderPage(ExamplePage, {
      route: '/organizations/:organizationId/some-collection/:collectionId/record/edit',
      url: '/organizations/2/some-collection/example-id/record/edit',
      search: '?someFilter=filter1',
    });

    await waitFor(() => // page has been rendered with all the necessary data
      expect(
        spies[
          `${API_BASE_URL}/some-collection/example-id?someFilter=filter1&organizationId=2`
        ],
      ).toHaveBeenCalledTimes(1),
    );

    const inputField = screen.getByDisplayValue(/example value/i);
    const saveChangesButton = screen.getByText(/Save changes/i);

    fireEvent.change(inputField, { target: { value: 'updated value' } }); // user action
    fireEvent.click(saveChangesButton); // user action

    await waitFor(() => // data draft has been sent
      expect(
        spies[
          `${API_BASE_URL}/some-collection/example-id/data-draft`
        ],
      ).toHaveBeenCalledTimes(1),
    );

    expect(screen.getByText(/Save some collection changes changes\?/i)).toBeInTheDocument();
    expect(screen.getByText(/updated value/i)).toBeInTheDocument();

    fireEvent.click(screen.getByText(/Confirm/i)); // user action

    await waitFor(() => // data has been submitted
      expect(
        spies[
          `${API_BASE_URL}/some-collection/example-id/data`
        ],
      ).toHaveBeenCalledTimes(1),
    );

    expect(
      screen.getByText(
        /Some collection records has been successfully changed./i,
      ),
    ).toBeInTheDocument();
  });

  // ...
});

Please share your thoughts about this matter and feel free to criticise my approach and suggest what would be better based on your commercial experience. Also, Happy New Year!

Do you implement logic first or focus on styling right-away?

chris-czopp — Sat, 18 Dec 2021 14:14:41 +0000

Hey React people! I'm just curious how you approach implementing dynamic UI which requires things like: app-state management, fetching data from API etc. For instance, I first focus on app-state, actions, any potential state kept in URL query params, dependencies in useEffect to re-fetch data upon action completion etc. Then, I write basic unstylled JSX to see it functional. Once I can click through major user journeys, I work on styling. What's your way?

Storecle - a neat app state management for React and Solid

chris-czopp — Thu, 25 Nov 2021 20:10:17 +0000

Storecle is a neat uni-directional app state management for React and Solid (❤️).

Features

Storecle uses a simple mental model which lets you access app-wide actions and their results by using Context API.
It consists of 4 main building blocks i.e. Store, User Actions (actions triggered by a user), Data Suppliers (actions executed prior to rendering) and Reload Types (action re-trigger groups).
The actions are just functions which are implicitly bound to the Store and write their results by returning/resolving.
Then, their results are accessible by their own names.

To improve the code re-usability, Data Suppliers use a middleware pattern. They are executed in the order you specify and pass a snapshot of Store from one to another, letting you split the logic into small, specified functions.

It works with both React and Solid (it's framework agnostic to certain degree).
It uses Context API and useEffect / createEffect to provide action re-triggers based on specified Store changes.
It facilitates splitting the business logic into granual, re-usable functions by applying a middleware pattern.
It simplifies naming and reduces noise by letting you access action results by their own names.
It provides an elegant approach to actions feeding UI with incoming data (e.g. from Web Sockets).
It is made to work with your IDE's code auto-completion.

Motivation

I ❤️ Redux, but it leaves plenty of room to be misused. Hence, Storecle is my proposal to let developers rely less on self-discipline and more on tooling and self-restrictive design.

To provide an easy way of separating app-wide logic from views i.e.:
- No inline: data fetches, transformers, conditionals.
- No nested action dispatchers upon other action completion.
To facilitate the action re-usability and modularization.
To provide a gradual path for React developers willing to use Solid.

Installation

React:

yarn add @gluecodes/storecle-react

npm i @gluecodes/storecle-react

Solid:

yarn add @gluecodes/storecle-solid

npm i @gluecodes/storecle-solid

It works along with either React or Solid that also needs to be installed in your app. For details, see their own documentations.

Usage

This module exports 3 constructs that can be imported for a particular framework in different parts of your app.

import { 
  builtInActions, 
  PageProvider, 
  useAppContext 
} from '@gluecodes/storecle-react'

import { 
  builtInActions, 
  PageProvider, 
  useAppContext 
} from '@gluecodes/storecle-solid'

For the purpose of the example I used a Solid version.

Soon the official starter templates will be released. Using this library means following certain patterns which are explained below using a simple counter example.

Mental Model

See: Code Sandbox example for React.

See: Code Sandbox example for Solid.

File tree:

.
├── actions
│   ├── dataSuppliers (#2)
│   │   └── index.js
│   ├── reloadTypes.js (#4)
│   └── userActions (#3)
│       └── index.js
├── index.jsx (#1)
├── Layout.jsx (#5)
└── partials (#6)
    └── Counter
        └── index.jsx

1. Page Container

Page provider wraps a given Layout around a single app context.

dataSupplierPipeline - an array providing the order in which Data Suppliers are executed.
dataSuppliers - an object containing Data Suppliers.
getLayout - a function which returns the page Layout.
reloadTypes - an object containing Reload Types.
userActions - an object containing User Actions.
onError - a function triggered when an error is thrown either in Data Suppliers or User Actions.

./index.jsx

import { PageProvider } from '@gluecodes/storecle-solid'

import * as dataSuppliers from './actions/dataSuppliers/index'
import * as userActions from './actions/userActions/index'
import * as reloadTypes from './actions/reloadTypes'

import Layout from './Layout.jsx'



export default () => (
  <PageProvider
    dataSupplierPipeline={[
      dataSuppliers.getTexts,
      dataSuppliers.getCounter
    ]}
    dataSuppliers={dataSuppliers}
    getLayout={() => Layout}
    reloadTypes={reloadTypes}
    userActions={userActions}
    onError={(err) => {
      console.error(err)
    }}
  />
)

2. Data Suppliers

Data suppliers provide data prior to rendering. Note the early returns which demonstrate how to resolve cached data based on Reload Type.

buildInActions - an object containing the following built-in User Actions:
- onStoreChanged - a function which receives a callback to be triggered when Store changes.
- runUserActions - a function which allows for executing multiple User Actions at once.
- runDataSuppliers - a function which receives a Reload Type name. Note that it's exposed to ease the integration with legacy apps. Don't call it manually as Data Suppliers are implicitly reloaded based on the provided Reload Types.
Each Data Supplier passes two arguments: resultOf and nameOf.
- resultOf - a function providing a result of a given Data Supplier or User Action.
- nameOf - a function providing a name of either Data Supplier, User Action or Reload Type.
Data Suppliers can be either sync or async and write to a central Store by returning/resolving.

./actions/dataSuppliers/index.js


import { builtInActions } from '@gluecodes/storecle-solid'
import { reFetchCounter } from '../reloadTypes'



export function getCounter (resultOf, nameOf) {
  const reloadType = resultOf(builtInActions.runDataSuppliers)
  const shouldFetch =
    reloadType === 'full' || reloadType === nameOf(reFetchCounter)

  if (!shouldFetch) {
    return resultOf(getCounter)
  }

  return global.sessionStorage.getItem('appWideCounter') || 0
}



export function getTexts (resultOf) {
  if (resultOf(builtInActions.runDataSuppliers) !== 'full') {
    return resultOf(getTexts)
  }

  return {
    Click: 'Click'
  }
}

3. User Actions

Actions triggered by a user.

./actions/userActions/index.js

export function incrementCounter (counter) {
  const incrementedCounter = Number(counter) + 1

  global.sessionStorage.setItem('appWideCounter', incrementedCounter)
}

4. Reload Types

A way to tell the app to re-run Data Suppliers based on executed User Actions.

A Reload Type groups User Actions together to tell the app to reload all Data Suppliers as a consequence of their execution.
When any of its User Actions is triggered, the app sets the Reload Type name under built-in runDataSuppliers and reloads all Data Suppliers.
Data Suppliers can benefit from caching by early returning their results based on Reload Type name.
Each Reload Type is a function which passes nameOf and returns an array of User Action names.
- nameOf - a function providing a name of User Action.

./actions/reloadTypes.js

import { incrementCounter } from './userActions/index'

export const reFetchCounter = (nameOf) => [
  nameOf(incrementCounter)
]

5. Layout

Nothing else than the page layout.

./Layout.jsx

import Counter from './partials/Counter/index.jsx'

export default () => (
  <div className='container'>
    <Counter />
  </div>
)

6. Partials

Partials are self-contained pieces of UI which have access to app state via the app context.

useAppContext - a function which returns an array of 3 items: resultOf, action, nameOf.
- resultOf - a function providing a result of a given Data Supplier or User Action.
- action - a function which triggers User Action.
- nameOf - a function providing a name of either Data Supplier or User Action.

./partials/Counter/index.jsx

import { useAppContext } from '@gluecodes/storecle-solid'

import { getCounter, getTexts } from '../../actions/dataSuppliers/index'
import { incrementCounter } from '../../actions/userActions/index'



export default () => {
  const [resultOf, action] = useAppContext()

  return (
    <button
      onClick={() => {
        action(incrementCounter)(
          resultOf(getCounter)
        )
      }}
    >{resultOf(getTexts)?.Click}: {resultOf(getCounter)}</button>
  )
}

Here is the open source Github repo. Feel free to suggest your ideas either in comments or in the repo issues. If you like it, a star would be appreciated 😉

How to override create-react-app jest config w/t restrictions

chris-czopp — Sat, 18 Sep 2021 10:28:06 +0000

The below snippet allows you to override react testing library to pass custom global variables to your jest tests. Sure, it is a hack but this way you can override any jest args without ejecting from create-react-app. Just run it instead of the standard test script 😉.

const fs = require('fs')
const vm = require('vm')
const jest = require('jest')

const extractJestArgsFromReactTestScript = () => {
  const sandbox = vm.createContext({
    capturedArgs: null,
    console,
    process,
    require: path => (
      require(path[0] === '.' ? `${__dirname}/../node_modules/react-scripts/scripts/${path}` : path)
    ),
    __dirname: `${__dirname}/../node_modules/react-scripts/scripts`
  });

  const testScriptContent = fs.readFileSync(`${__dirname}/../node_modules/react-scripts/scripts/test.js`, 'utf8')

  const scriptAsArray = testScriptContent
    .trim()
    .split('\n')

  scriptAsArray.pop()
  scriptAsArray.push('capturedArgs = argv')

  const scriptToRun = scriptAsArray.join('\n')

  vm.runInContext(scriptToRun, sandbox)

  return sandbox.capturedArgs
};

const capturedArgs = extractJestArgsFromReactTestScript()
const jestConfigValueArgIndex = capturedArgs.findIndex(arg => arg === '--config') + 1
const jestOverriddenConfig = JSON.parse(capturedArgs[jestConfigValueArgIndex])
const overriddenArgs = [...capturedArgs]

jestOverriddenConfig.globals = Object.assign(jestOverriddenConfig.globals || {}, {
  someGlobal: 'hello!'
})

overriddenArgs[jestConfigValueArgIndex] = JSON.stringify(jestOverriddenConfig)

jest.run(overriddenArgs)

What JS frameworks fail at that makes the new ones being developed so often?

chris-czopp — Wed, 16 Jun 2021 12:19:58 +0000

Any thoughts? Aren't we in some sort of limbo?

5 reactive UI interactions you'd better did instead of querying $elements

chris-czopp — Tue, 15 Jun 2021 17:56:14 +0000

Introduction

This article is dedicated for a web developer who appreciates design freedom, yet who'd like to code less in a setup-free web-based development environment.

It's a 5 DOM interaction you'd better did in a reactive way instead of using jQuery or document.querySelector.

Why? - Because it's more maintainable and scalable. You can read more in one of my past articles.

The below snippets are meant to work with GlueCodes Studio - the tool powering your every-day work in the ways you haven't seen elsewhere. It's for somebody who'd be pleased with loads of automation to deliver an extremely fast and scalable code i.e. build-time diffed JSX using SolidJS organised around an implicit uni-directional data flow. Obviously you can use it for FREE, so let's begin!

1. Updating a CSS class on a button click

<button-x>
  <script>
    if (uiSignals.updateClass) {
      props.className = 'some-class'
    }

    props.onClick = () => {
      uiSignals.updateClass = true
    }
  </script>Click
</button-x>

2. Toggling a CSS class on a button click

<button-x>
  <script>
    if (uiSignals.updateClass) {
      props.className = 'some-class'
    }

    props.onClick = () => {
      uiSignals.updateClass = !uiSignals.updateClass
    }
  </script>Click
</button-x>

Note: The snippets are made using a concept called "extended tags". Below you'll be seeing a global uiSignals object being accessed in embedded <script>s. You can freerly set/get properties on/of this object. Think of it as a local UI state, something you'd see in React as hooks. What matters the most is that when a property of uiSignals changes, only the DOM elements which access it get updated.

3. Switching tabs

<span-x>
  <script>
    if (uiSignals! || uiSignals.activeTab === 'a') {
      props.className = 'active'
    }

    props.onClick = () => {
      uiSignals.activeTab = 'a'
    }
  </script>Default tab (A)
</span-x>
<span-x>
  <script>
    if (uiSignals.activeTab === 'b') {
      props.className = 'active'
    }

    props.onClick = () => {
      uiSignals.activeTab = 'b'
    }
  </script>B
</span-x>
<span-x>
  <script>
    if (uiSignals.activeTab === 'c') {
      props.className = 'active'
    }

    props.onClick = () => {
      uiSignals.activeTab = 'c'
    }
  </script>C
</span-x>

4. Removing an element on a button click

<div>
  <button-x>
    <script>
      props.onClick = () => {
        uiSignals.shouldTheSpanBeRemoved = true
      }
    </script>
  </button-x>
  <span-x gc-as="conditional">
    <script>
      props.isConditionMet = uiSignals.shouldTheSpanBeRemoved
    </script>
  </span-x>
</div>

5. Adding an item to the list

<div>
  <input-x>
    <script>
      props.onKeyUp = async (e) => {
        if (e.code === 'Enter') {
          await actions.submitRecord(e.target.value)
          actions.reload()
        }
      }
    </script>
  </input-x>
  <ul>
    <li gc-as="listItemPresenter" gc-provider="getSomeRecords">
      <fragment gc-as="varPresenter" name="getSomeRecordsItem">repeated item</fragment>
    </li>
  </ul>
</div>

There are some more directives in this snippet which you can read about here. Note that when an extended tag is placed inside a "list item presenter", you get access to a variable called: providerName + Item, in our case getSomeRecordsItem which is an item while looping over getSomeRecords action result (an array). You could also access getSomeRecordsIndex for a numeric index in the array.

What are those tagName-x tags?

Static HTML has no built-in way to make it reactive. Hence, GlueCodes Studio supports a concept called extended tags which is named like: tagName + '-x' and has an embedded <script> included. Its code is sandboxed allowing you to access variables which are available inside other directives including slots or list item presenters. In the script you can assign to props variable to change props/attributes of the "extended" tag. For a complete list of the directives click here.

What's next?

Before you shout "this is another self-promotional read", I'll say yeah, this article is indeed about a new tool. But, bear in mind it's made by two developers who want to address the problem differently. And we're not a corporation. I'm trying to share with you a new way where you can use a slightly extended old-fashion HTML to build reactive apps. So if you like the idea of managing local UI state using the extended tags and attribute directives, you may want to read more in our documentation.

Also join our Facebook forum for help and support. Thanks!

How to build a restaurant listing UI for Strapi using GC & GraphQL

chris-czopp — Thu, 10 Jun 2021 17:07:17 +0000

Intro

This article is dedicated for a web developer who appreciates design freedom, yet who'd like to code less in a setup-free web-based development environment.

It's a "how to" integrate with Strapi using GlueCodes Studio - the tool powering your every-day work in the ways you haven't seen elsewhere. It's for somebody who'd be pleased with loads of automation to deliver an extremely fast and scalable code i.e. build-time diffed JSX using SolidJS and organised around an implicit uni-directional data flow. Obviously you can use it for FREE. Without further "context drawing", let's begin.

What are we building?

We're going to use Strapi as a headless CMS. It comes with a hosted demo for an imaginary Food Advisor site and it's already seeded with restaurant data. You can request your instance here. After filling in a form, you'll receive an email with few URLs. Mine looked like these:

Demo URL: https://api-hi2zm.strapidemo.com/admin

API restaurants URL: https://api-hi2zm.strapidemo.com/restaurants

GraphQL URL: https://api-hi2zm.strapidemo.com/graphql

Credentials: john@doe.com / welcomeToStrapi123

Don't try to be a smartass, the URLs won't work longer that the demo duration you provided in the demo form.

I won't be covering how to use Strapi, just explore it yourself if you like. For our tutorial all you'll need is these two URLs:

GraphQL:
https://api-{someHash}.strapidemo.com/graphql

Image Server:
https://api-{someHash}.strapidemo.com

Our app will have the following features:

grid of restaurants with names, description, category and image
filtering by category
filtering by neighborhood
filtering by language
pagination

The app will apply the filters without the browser hard-reload, meaning it'll be SPA. In Part 1, we will focus on the Strapi integration and leave pagination and mobile responsiveness for Part 2. I'll leave any styling improvements to you as it isn't a CSS tutorial. It'll look like this:

Coding

First, you'll need go to: GlueCodes Studio. You'll be asked to sign up via Google or Github. No worries, it won't require any of your details. Once you're in the project manager, choose "Strapi Food Advisor" template. You'll be asked to choose a directory where the project suppose to be stored. Just choose one and you should be redirected to IDE.

You might be welcomed with some introjs walk-through(s) guiding you around something like this:

As mentioned above, you'll need two URLs:

GraphQL:
https://api-{someHash}.strapidemo.com/graphql

Image Server:
https://api-{someHash}.strapidemo.com

Let's add them to Global Variables as GQL_URL and IMAGE_BASE_URL:

Now you can click "Preview" to see the working app.

App data flow design

We'll need a list of restaurants pulled from Strapi's GraphQL API. GlueCodes Studio has a built-in data flow management. Your business logic is spread across app actions which store their returned/resolved values in a single object store. The data changes flow in one direction and UI reacts to changes of the store, updating the only affected parts. The DOM diffing happens in-compilation time and is powered by SolidJS.

There are two types of actions; the ones that supply data before rendering called providers and those triggered by a user called commands. Their both returned/resolved values are accessible from a single object store by their own names. In your UI, you get access to global variables: actions and actionResults. The variable actions is an object of Commands you can call to perform an action e.g. to return/resolve fetched data. You can read more in docs. It's really easier done than said so bear with me.

The API call we're going use returns restaurants along with categories. Our app also needs a list of neighborhoods and parse URL query parameters to affect the GraphQL call. We'll also need some basic data transformations before passing it to our UI. Based on this information, I decided to have the following providers:

fetchRestaurantData
getCategories
getLanguages
getNeighborhoods
getRestaurants
parseUrlQueryParams

For filtering, we'll need the following commands:

changeCategory
changeLanguage
changeNeighborhood

I'll walk you through them one by one but before, you need to understand the mechanism of providers a bit further. Note that providers, when returning they implicitly write to a single object store by their own names. Then, a snapshot of this store is passed from one provider to another. It means you can access results of the previously called providers. It also means you need to set their execution order. It's done by navigating to a particular provider and clicking "Run After" button and in its corresponding pane, choose which providers need to be executed before. You can expect something like this:

We want to achieve the following pipeline:

The fetchRestaurantData uses a result of parseUrlQueryParams.

The getRestaurants and getCategories use a result of fetchRestaurantData.

It can look like this:

getNeighborhoods
parseUrlQueryParams
fetchRestaurantData
getRestaurants
getLanguages
getCategories

OK, let's dive into functions now.

Actions

providers/fetchRestaurantData:

export default async (actionResults) => {
  const { category, district, locale } = actionResults.parseUrlQueryParams 

  const where = {
    locale: 'en'
  }

  if (category !== 'all') {
    where.category = category
  }

  if (district !== 'all') {
    where.district = district
  }

  if (locale) {
    where.locale = locale
  }

  const query = `
    query ($limit: Int, $start: Int, $sort: String, $locale: String, $where: JSON) {
      restaurants(limit: $limit, start: $start, sort: $sort, locale: $locale, where: $where) {
        id
        description
        district
        cover {
          url
        }
        category {
          name
        }
        name
        locale
        localizations {
          id
          locale
        }
        note
        price
        reviews {
          note
          content
        }
      }
      restaurantsConnection(where: $where) {
        aggregate {
          count
        }
      }
      categories {
        id
        name
      }
    }
  `

  const records = await (await fetch(global.GQL_URL, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      query,
      variables: {
        limit: 15,
        start: actionResults.parseUrlQueryParams.start || 0,
        sort: 'name:ASC',
        locale: 'en',
        where
      }
    })
  })).json()

  return records.data
}

Notes:

actionResults.parseUrlQueryParams accesses the query URL params
global.GQL_URL accesses the GQL_URL global variable

providers/getCategories:

export default (actionResults) => {
  return [
    {
      id: 'all',
      name: 'All'
    },
    ...actionResults.fetchRestaurantData.categories  
  ]
}

Notes:

actionResults.fetchRestaurantData.categories accesses the categories which are part of fetchRestaurantData result

providers/getLanguages:

export default () => {
  return [
    {
      id: 'en',
      name: 'En'
    },
    {
      id: 'fr',
      name: 'Fr'
    }
  ]
}

providers/getNeighborhoods:

export default () => {
  return [
    { name: 'All', id: 'all' },
    { name: '1st', id: '_1st' },
    { name: '2nd', id: '_2nd' },
    { name: '3rd', id: '_3rd' },
    { name: '4th', id: '_4th' },
    { name: '5th', id: '_5th' },
    { name: '6th', id: '_6th' },
    { name: '7th', id: '_7th' },
    { name: '8th', id: '_8th' },
    { name: '9th', id: '_9th' },
    { name: '10th', id: '_10th' },
    { name: '11th', id: '_11th' },
    { name: '12th', id: '_12th' },
    { name: '13th', id: '_13th' },
    { name: '14th', id: '_14th' },
    { name: '15th', id: '_15th' },
    { name: '16th', id: '_16th' },
    { name: '17th', id: '_17th' },
    { name: '18th', id: '_18th' },
    { name: '19th', id: '_19th' },
    { name: '20th', id: '_20th' }
  ]
}

providers/getRestaurants:

export default (actionResults) => {
  return actionResults.fetchRestaurantData.restaurants
    .map((record) => ({
      id: record.id,
      name: record.name,
      description: record.description,
      category: record.category.name,
      district: record.district,
      thumbnail: record.cover[0].url
    }))
}

Notes:

actionResults.fetchRestaurantData.restaurants accesses the restaurants which are part of fetchRestaurantData result

providers/parseUrlQueryParams:

export default (actionResults) => {
  return imports.parseUrlQueryParams()
}

Notes:

imports.parseUrlQueryParams accesses an external dependency function.

In GlueCodes Studio you can use any UMD-bundled modules including those in UNPKG. Just click on Dependencies icon and edit the JSON file to look like:

{
  "css": {
    "bootstrap": "https://unpkg.com/bootstrap@4.5.2/dist/css/bootstrap.min.css",
    "fa": "https://unpkg.com/@fortawesome/fontawesome-free@5.14.0/css/all.min.css"
  },
  "js": {
    "modules": {
      "parseUrlQueryParams": "https://ide.glue.codes/repos/df67f7a82cbdc5efffcb31c519a48bf6/basic/reusable-parseUrlQueryParams-1.0.4/index.js",
      "setUrlQueryParam": "https://ide.glue.codes/repos/df67f7a82cbdc5efffcb31c519a48bf6/basic/reusable-setUrlQueryParam-1.0.4/index.js"
    },
    "imports": {
      "parseUrlQueryParams": {
        "source": "parseUrlQueryParams",
        "importedName": "default"
      },
      "setUrlQueryParam": {
        "source": "setUrlQueryParam",
        "importedName": "default"
      }
    }
  }
}

commands/changeCategory:

export default (categoryId) => {
  imports.setUrlQueryParam({ name: 'category', value: categoryId })
}

Notes:

imports.setUrlQueryParam accesses an external dependency function

commands/changeLanguage:

export default (languageId) => {
  imports.setUrlQueryParam({ name: 'locale', value: languageId })
}

commands/changeNeighborhood:

export default (neighborhoodId) => {
  imports.setUrlQueryParam({ name: 'district', value: neighborhoodId })
}

Structure

In GlueCodes Studio each page is split into logical UI pieces to help you keep your UI modular. A single slot has its scoped CSS which means it can be styled by classes which only affect a given slot and their names can be duplicated in other slots. In the exported code, slots will be extracted to dedicated files making them more maintainable.

To make your HTML dynamic, you can use attribute directives as you would in modern web frameworks. When typing most of them, you'll get notified to auto-create (if don't exist) required commands, providers or to install a widget. The vocabulary is quite simple, attribute [gc-as] tells what it is and other [gc-*] attributes are parameters. Note: For any naming attributes use camelcase e.g. for a slot you would use [gc-name="myAwesomeSlot"].

Here is a slightly stripped-out index page HTML:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
  <meta gc-as="navName" gc-name="Home">
  <title>FoodAdvisor</title>
<body>
  <div gc-as="layout">
    <div class="container-fluid">
      <div gc-as="slot" gc-name="header"></div>
      <div class="d-flex">
        <div gc-as="slot" gc-name="filters"></div>
        <div gc-as="slot" gc-name="content">
          <div class="contentWrapper">
            <h1 class="heading">Best restaurants in Paris</h1>
            <div class="grid">
              <div gc-as="listItemPresenter" gc-provider="getRestaurants" class="card">
                <img-x class="card-img-top thumbnail" alt="Card image cap">
                  <script>
                    props.src = `${global.IMAGE_BASE_URL}${getRestaurantsItem.thumbnail}`
                  </script>
                </img-x>
                <div class="card-body">
                  <h4 gc-as="listFieldPresenter" gc-provider="getRestaurants" gc-field="name" class="name">restaurant name</h4>
                  <h5 gc-as="listFieldPresenter" gc-provider="getRestaurants" gc-field="category" class="category">restaurant category</h5>
                  <p gc-as="listFieldPresenter" gc-provider="getRestaurants" gc-field="description" class="card-text">restuarant description</p>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <div gc-as="slot" gc-name="footer"></div>
    </div>
  </div>
</body>
</html>

Notes:

<div gc-as="layout"> is the app wrapper.
<div gc-as="slot" gc-name="content"> is a logical UI piece which has its scoped CSS and is extracted to dedicated file. It requires a unique (within page) camelcase gc-name. Whatever is in slot gets access to a store, commands and other useful variables. You can learn more here.
<div gc-as="slot" gc-name="filters"></div> is a reusable slot. Similar to a slot however it can be used across multiple pages. Reusable slots can be understood as partials. You'll be editing reusable slots in a dedicated HTML editor and injecting them in pages using empty slot directive.
<div gc-as="listItemPresenter" gc-provider="getRestaurants" class="card"> repeats this div over an array returned by getRestaurants provider.
<h4 gc-as="listFieldPresenter" gc-provider="getRestaurants" gc-field="name" class="name">restaurant name</h4> displays a property name of an item while looping over getRestaurants provider.

Let's take a look at this once more:

<img-x class="card-img-top thumbnail" alt="Card image cap">
  <script>
    props.src = `${global.IMAGE_BASE_URL}${getRestaurantsItem.thumbnail}`
  </script>
</img-x>

Static HTML has no built-in way to make it reactive. Hence GlueCodes Studio has a concept called extended tags which is named like: tagName + '-x' and has an embedded <script> included. Its code is sandboxed allowing you to access variables which are available inside other directive like slots or list item presenters. The scripts can assign to props variable to change props/attributes of the extended tag.

Note that when an extended tag is placed inside a list item presenter you get access to a variable called like: providerName + Item, in our case getRestaurantsItem which is an item while looping over getRestaurants provider. You could also access getRestaurantsIndex for a numeric index in the array.

Other Templates:

reusableSlots/filters:

<div class="wrapper">
  <h2 class="heading">Categories</h2>
  <ul class="filterSet">
    <li gc-as="listItemPresenter" gc-provider="getCategories" class="filterItem">
      <label>
        <input-x type="radio">
          <script>
            props.name = 'category'
            props.value = getCategoriesItem.id
            props.checked = getCategoriesItem.id === (actionResults.parseUrlQueryParams.category || 'all')
            props.onChange = (e) => {
              actions.changeCategory(e.target.value)
              actions.reload()
            }
          </script>
        </input-x>
        <span gc-as="listFieldPresenter" gc-provider="getCategories" gc-field="name" class="label">category name</span>
      </label>
    </li>
  </ul>
  <h2 class="heading">Neighborhood</h2>
  <ul class="filterSet">
    <li gc-as="listItemPresenter" gc-provider="getNeighborhoods" class="filterItem">
      <label>
        <input-x type="radio">
          <script>
            props.name = 'neighborhood'
            props.value = getNeighborhoodsItem.id
            props.checked = getNeighborhoodsItem.id === (actionResults.parseUrlQueryParams.district || 'all')
            props.onChange = (e) => {
              actions.changeNeighborhood(e.target.value)
              actions.reload()
            }
          </script>
        </input-x>
        <span gc-as="listFieldPresenter" gc-provider="getNeighborhoods" gc-field="name" class="label">neighborhood name</span>
      </label>
    </li>
  </ul>
  <h2 class="heading">Language</h2>
  <ul class="filterSet">
    <li gc-as="listItemPresenter" gc-provider="getLanguages" class="filterItem">
      <label>
        <input-x type="radio">
          <script>
            props.name = 'languages'
            props.value = getLanguagesItem.id
            props.checked = getLanguagesItem.id === (actionResults.parseUrlQueryParams.locale || 'en')
            props.onChange = (e) => {
              actions.changeLanguage(e.target.value)
              actions.reload()
            }
          </script>
        </input-x>
        <span gc-as="listFieldPresenter" gc-provider="getLanguages" gc-field="name" class="label">language name</span>
      </label>
    </li>
  </ul>
</div>

reusableSlots/footer:

<footer class="wrapper">
  <p>Try <a href="https://www.glue.codes" class="link">GlueCodes Studio</a> now!</p>
  <ul class="nav">
    <li class="navItem">
      <a href="https://www.facebook.com/groups/gluecodesstudio" class="navLink"><i class="fab fa-facebook"></i></a>
    </li>
    <li class="navItem">
      <a href="https://www.youtube.com/channel/UCDtO8rCRAYyzM6pRXy39__A/featured?view_as=subscriber" class="navLink"><i class="fab fa-youtube"></i></a>
    </li>
    <li class="navItem">
      <a href="https://www.linkedin.com/company/gluecodes" class="navLink"><i class="fab fa-linkedin-in"></i></a>
    </li>
  </ul>
</footer>

reusableSlots/header:

<nav class="navbar navbar-light bg-light wrapper">
  <a class="navbar-brand link" href="/">
    <img-x width="30" height="30" alt="FoodAdvisor" class="logo">
      <script>
        props.src = mediaFiles['logo.png'].src
      </script>
    </img-x> FoodAdvisor
  </a>
</nav>

You can access any images or videos you drop in the studio via mediaFiles variable which is an object where file names are the keys. Implicitly there is a Webpack Responsive Loader involved which gives you src and placeholder.

Styles

For styling, although it feels like coding oldschool HTML and CSS, you'll be implicitly using CSS Modules. GlueCodes Studio gives you a beautiful balance between scoped and global styling. So, you can theme your app globally and at the same time style chosen parts of the UI in isolation. You'll simply be using CSS classes and because of the implicit scoping you can safely duplicate class names among different slots.

Notice a rather unusual @import statements. It's a way of importing third-party CSS from dependencies or global styles. The names must match the ones in Dependencies JSON or name of a global stylesheet.

pages/index/This Page CSS

@import 'bootstrap';

pages/index/Content Slot CSS

@import 'bootstrap';
@import 'fa';
@import 'theme';

.contentWrapper {
  padding: 0 20px;
}

.grid {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-gap: 30px;
  margin-top: 40px;
}

.heading {
  margin-bottom: 0;
  font-size: 32px;
}

.thumbnail {
  transition: transform 0.3s;
}

.thumbnail:hover {
  transform: translateY(-4px); 
}

.name {
  font-weight: 700;
  font-size: 16px;
  color: rgb(25, 25, 25);
}

.category {
  font-size: 13px;
  color: #666;
}

reusableSlots/filters:

.wrapper {
  padding: 0 20px;
  padding-top: 75px;
  min-width: 250px;
}

.filterSet, .filterItem {
  margin: 0;
  padding: 0;
}

.filterSet {
  margin-bottom: 30px;
}

.filterItem {
  list-style: none;
}

.filterItem label {
  cursor: pointer;
}

.label {
  padding-left: 4px;
}

.heading {
  padding-bottom: 15px;
  font-weight: 700;
  font-size: 16px;
  color: rgb(25, 25, 25);
}

reusableSlots/footer:

@import 'fa';

.wrapper {
  margin-top: 70px;
  padding: 20px;
  background-color: #1C2023;
  color: white;
}

.link {
  color: white;
}

.link:hover {
  color: #219F4D;
  text-decoration: none;
}

.nav {
  display: flex;
  margin: 0;
  padding: 0;
}

.navItem {
  list-style: none;  
}

.navLink {
  display: inline-block;
  margin-right: 2px;
  width: 40px;
  height: 40px;
  line-height: 40px;
  text-align: center;
  font-size: 18px;
  border-radius: 50%;
  background-color: #272a2e;
}

.navLink,
.navLink:hover,
.navLink:active,
.navLink.visited {
  text-decoration: none;
  color: white;
}

.navLink:hover {
  background-color: #219F4D;
}

reusableSlots/header:

.wrapper {
  padding: 20px;
  background: #1C2023;
  margin-bottom: 30px;
}

.link {
  color: white;
  font-size: 18px;
  font-weight: 700;
}

.link,
.link:hover,
.link:active,
.link:visited {
  color: white;
  text-decoration: none;
}

.logo {
  margin-right: 3px;
}

What's next?

As you may have noticed there is a tone of details which hopefully is reasonably absorbable. I'll share a direct link to the project soon after releasing this article. Enjoy building your custom CMSs with GlueCodes Studio and Strapi.

Let me know whether I should write Part 2 or if there is some other integration you'd love to see.

Also, join our Facebook Forum

1 good thing you can do this weekend for web dev

chris-czopp — Sat, 05 Jun 2021 12:51:31 +0000

I just posted my project on Product Hunt. It's a front-end studio for those developers who are hooked in build-time DOM diffing and awesome automation. If you like it, upvote my product 🙏 as it's super important to get the early boost which will keep us higher on their listings so we're noticed.

Here is the product: GlueCodes Studio

Ready to move from jQuery to shiny reactivess?

chris-czopp — Sat, 29 May 2021 15:54:32 +0000

If you're a modern framework user, you may laugh at jQuery but somehow it's still widely used and even frontend newcomers often begin their dev journey with the devil $. I wrote this article for both - jQuery users and those who use modern frameworks to make them aware that while we're focusing on high level framework related problems, there are still incoming jQuery folks.

Why people choose it over frameworks? ...I don't know, maybe it's because the entry tech barrier isn't that high. It doesn't require many tools and libs in order to start adding interactivity here and there. Also, it uses selectors many of which you can use in a regular document.querySelector() or document.querySelectorAll() these days. Anyway, I'm not a fan boy of jQuery, so enough of this attempt of understanding why. And, I think you shouldn't use it anymore nor bother learning it, unless you like learning for the sake of learning. I'm not going to even say it's OK to use it in small projects because many of them quickly evolve to bigger ones.

Why not $

There is already native support of document.querySelector() and document.querySelectorAll()
ES6+ brought plenty of native goodies you can use instead of the jQuery's "convenience" functions. I mean, I have nothing against shortcuts in dev but what I've been seeing often is that people become the prisoners of their tools. They are forcing themselves to use jQuery for every possible piece of logic, even though it could be done simpler natively.
Modern web apps must be interactive but at the same time maintainable. And, keeping data in HTML and reshaping it with manual DOM manipulations leads to repetition and multiple sources of truth. It becomes a mess which doesn't scale.
For styling, there is a sophisticated technology called CSS. So, you don't need to .show() or .hide()
Styling directly from JS (using .css()), despite the fact it makes my eyes bleeding, leads to repetition and just violates what CSS stands for. As a reminder, it's a cascading style sheets ...and I won't go on this.
Abstracting away things like: element.addEventListener('click', ...) with: element.click(...) doesn't bring any benefits anymore and renaming the native JS API causes unnecessary confusion.

Why being reactive

By reactive, I don't mean using React and if I would promote anyone here I would SolidJS but it's something for a different article. It's about a conceptual model which is built on the following pillars:

A classical separation of structure (HTML), styles (CSS) and any dynamic interactions (JS).
Separation of data from the view inspired by a family of MV* patterns.
Declarative way of constructing UI which means the markup can be understood as a DSL describing UI in its any possible states driven by outside data.
Modularisation, personally I value pure functions over classes and their pureness gives the self-contained feel you'd expect from a component.

So why being reactive? There is already a few hints above, but let me explain it a bit further. It's certainly not about being fancy and a CV-driven development or whatsoever. It provides real benefits. It gives you a long-term maintainability and helps you tweak your projects without the need of understanding the whole codebase. In short, it makes your and your teammates lives more enjoyable and allows you to deliver more features sooner without breaking everything around (automated tests would be a cherry on the cake).

Objections

So if you're are a jQuery guy, you might be moaning that it's all cool but with jQuery you can jump straight into adding stuff. Other tools require bazillion of tools around the main tool. So, from toggling an element you have to go through the whole spectrum of skills and there is no time for that. The budget is tight...

Well, I totally get it. But, you can't sacrifice all the aspects of decades of dev evolution only because something seems to be simpler.

There are many great frameworks out there, starter boilerplates and automation tools. Since I write this article as an owner of such a tool, and I genuinely believe I significantly lowered the tech-barrier for newcomers and the simplicity enthusiasts, I'll allow myself for self-promotion.

So, dear jQuery developer: what if I told you that I made a tool which lets you jump straight into coding ultra-fast apps that scale? And, that you'd be using classic HTML, CSS and JS without worrying about any glueing code. It would be preorganised, and you'd be driving your UI states declaratively by data by using HTML attributes. Would it be cool? So here: 👉 GlueCodes Studio, go and just enjoy writing reactive apps which you can export to self-contained SolidJS codebase. Whether you experienced or new to frontend dev, with a little of learning, I'm sure you will never want to get back to jQuery.

🙏 Let me know if anything above got your interest and I'd be glad to guide you through the mental conversion going from jQuery to the reactiveness.

5 Reasons why we chose to transpile to SolidJS instead of React

chris-czopp — Wed, 26 May 2021 09:02:03 +0000

Choosing a relatively young framework with a limited support over Facebook's giant may seem like craziness. As a core developer at GlueCodes Studio, I was the one pushing towards taking the risk. The decision has been mainly driven by Solid's build-time DOM diffing flavoured with a very simple API. I really believe it's a natural replacement of Virtual DOM. I always believed that taking the compromise of re-rendering the whole tree when the app state changes just for a "developer's convenience" is a matter of time. There was Svelte on radar, but I'm rather in favour of JSX, especially because we already provide an abstraction layer for templating using HTML with our meta-framework specific directives. So, I thought it would be awesome to write UIs with this higher level of abstraction and export to more flexible JSX and if you wish, continue development out of our tool. Check out the docs for more info.

Here are the 5 points:

It does DOM diffing at build-time.
It's function-first and it has a very clean API. Much of it is similar to React.
It doesn't recursively call the component every time the app state changes. I mean the body of the function which returns JSX is called just once, making local state management simpler and more natural.
It is primary made for JSX, but there is also HyperScript available which can be handy if you need DOM diffing at run-time. In our case, it was useful for Live Preview without compilation.
A component returns a DOM element!

💪 Bonus: It's owned by the community and the core team is very open and responsive.

Links:

SolidJS

GlueCodes Studio

Let me know what you think.

How you'd write a reactive calculator with x-HTML in 5 mins

chris-czopp — Mon, 24 May 2021 20:25:25 +0000

In this article you won't see the millionth way of writing a calculator with the tools that are well covered by many others. Instead, I'm going to show you how to do it with much less effort in a tool you probably haven't heard of yet. And it is a big deal since it automates and abstracts away frontend web app development by the ways you haven't seen elsewhere. And yeah, the calculator is a trivial app, yet it's a good example to present a few interesting concepts.

OK, enough of the intro, here are few steps to follow:

Go to: https://ide.glue.codes.
Create a new project.
Write the below code, you can click preview to see changes as your'e typing.
Export it to a self-contained app based on SolidJS and JSX.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
  <meta gc-as="navName" gc-name="Home">
  <title>Calculator</title>
</head>
<body>
  <div gc-as="layout">
    <div class="container">
      <div gc-as="slot" gc-name="content">

        <input-x type="number">
          <script>
            props.onChange = (e) => {
              uiSignals.numberA = parseInt(e.target.value)
            }
          </script>
        </input-x>

        <select-x>
          <script>
            props.onChange = (e) => {
              uiSignals.operator = e.target.value
            } 
          </script>
          <option value="+">+</option>
          <option value="-">-</option>
          <option value="*">*</option>
          <option value="/">/</option>
        </select-x>

        <input-x type="number">
          <script>
            props.onChange = (e) => {
              uiSignals.numberB = parseInt(e.target.value)
            }
          </script>
        </input-x>

        <span>=</span>

        <input-x type="number">
          <script>
            switch (uiSignals.operator) {
              case '-':
                props.value = uiSignals.numberA - uiSignals.numberB
                break

              case '*':
                props.value = uiSignals.numberA * uiSignals.numberB
                break

              case '/':
                props.value = uiSignals.numberA / uiSignals.numberB
                break

              case '+':
              default: 
                props.value = uiSignals.numberA + uiSignals.numberB
            }

          </script>
        </input-x>

      </div>
    </div>
  </div>
</body>
</html>

What just happened?

Well, the above code certainly wouldn't work if you dropped it into a regular HTML file. In a traditional way, you'd need to have a script below the document and manually query for an element and then update it. It could work in a small app which you don't plan to extend. But, if you need your UI to be reactive and at the same time maintainable you'd opt for some reactive framework or library. Perhaps JSX so your UI looks like HTML but it can be interpolated with dynamic data in a declarative fashion. That can be done beautifully with SolidJS and it will diff DOM at build-time as opposed to what many other frameworks/libraries do i.e. using Virtual DOM. It's all great but wouldn't it be cool to use HTML where possible and extend it to be reactive where necessary? This is exactly what you see in the code above.

It's a combination of extended tags and UI signals to mange the local state. At GlueCodes, we introduced extended tags which are named: tagName + '-x' and have an embedded <script> allowing you to access variables available in the scope where they have been placed. The scripts can assign to props variable to change props/attributes of the extended tag. In this case, you can see writing/reading uiSignals which holds some sort of observables and it'll update any props they are assigned to. What you see is a meta-framework abstracting away the signals. See SolidJS.

Notice the uiSignals are scoped to a slot/partial they are in and an HTML tag is told to be a slot by using one of many HTML directives:

<div gc-as="slot" gc-name="content">
...
</div>

So, in addition to extended tags, you can make your HTML dynamic by using attribute directives as you would in modern web frameworks. When typing most of them you'll get notified to auto-create (if don't exist) required actions or to install a widget. The vocabulary here is simple, an attribute [gc-as] tells what it is and other [gc-*] attributes are parameters.

The above code can be split into 4 parts. An embedded script tag in each of the extended tag allows to modify their props e.g. register events or set a value on an input. It modifies only the props of its direct parent tag.

1) Capturing the first number:

<input-x type="number">
  <script>
    props.onChange = (e) => {
      uiSignals.numberA = parseInt(e.target.value)
    }
  </script>
</input-x>

2) Capturing the operator:

<select-x>
  <script>
    props.onChange = (e) => {
      uiSignals.operator = e.target.value
    } 
  </script>
  <option value="+">+</option>
  <option value="-">-</option>
  <option value="*">*</option>
  <option value="/">/</option>
</select-x>

3) Capturing the second number:

<input-x type="number">
  <script>
    props.onChange = (e) => {
      uiSignals.numberB = parseInt(e.target.value)
    }
  </script>
</input-x>

4) Displaying the result of equation:

<input-x type="number">
  <script>
    switch (uiSignals.operator) {
      case '-':
        props.value = uiSignals.numberA - uiSignals.numberB
        break

      case '*':
        props.value = uiSignals.numberA * uiSignals.numberB
        break

      case '/':
        props.value = uiSignals.numberA / uiSignals.numberB
        break

      case '+':
      default: 
        props.value = uiSignals.numberA + uiSignals.numberB
    }

  </script>
</input-x>

That's it about the UI signals. There is tons of features provided by GlueCodes Studio. Widgets, built-in app state management, implementation assistant and many more. The most importantly it runs in the browser and stores the project metadata and the exported SolidJS code on your hard drive!

Looking forward to see your feedback!