digitalsadhu

This is a very challenging space with multiple moving parts. React is not super friendly to DSD when hydrating. The Lit team has created packages to try to make things "play nice" but as we shall see, this is not smooth sailing.

A basic solution

Heres a simple Lit element component that we register as my-web-component.

import { LitElement, html, css } from "lit";

digitalsadhu

Migrating to Eik v2

Terminology

• MUST For things to work as expected, it is required that you perform tasks listed as must
• SHOULD While not strictly necessary, performing tasks listed as should will help line you up with what we consider our current best practices
• CAN Your call, on this one. We think it's a good idea but YMMV.

TLDR;

• MUST Update modules to v2

digitalsadhu

MVP Features

In a web app, it should be possible to:

• Login with discord account
• manage your token images
  • upload, delete, name, set match strings
• manage your maps
  • upload, delete, name, define settings such as grid size etc
• access your personal token

digitalsadhu

The issue

1. Typescript converts to a js version with jsx files This is just Lars' build step that outputs to a /lib folder

2. I add a rollup build to convert out the jsx so its pure js with esm

import resolve from '@rollup/plugin-node-resolve';
import commonjs from '@rollup/plugin-commonjs';

digitalsadhu

I’ve done a little digging. I think we have some challenges to solve regarding supporting both Eik and Asset pipe in the manifest file.

Notes

1. in the manifest file must have the legacy field populated with asset pipe hash and the new js and css arrays must be populated with Eik absolute URLs
2. the first time podlet.js or podlet.css is called, the legacy field is populated, subsequent calls do not reset the legacy field so it is important that the asset pipe stuff is done before the Eik stuff
3. Even when podlet.js and podlet.css are called in the correct order, the legacy field is added to the array of modern fields

Examples

digitalsadhu

Publishing from CI, 2 approaches

Approach 1. [current approach] (where the cli controls the version)

• eik package
  • calculates hashes of a local build and compares with what is available on the server
    • if hashes are the same, abort
  • calculates the next version number to publish
    • for a patch 1.0.1 goes to 1.0.2
• for a minor 1.0.1 goes to 1.1.0

digitalsadhu

Asset Server Proposed cli commands

All commands rely on the existance of an .assets.json file which will can be in the users home directory and/or the root of the project directory with a file in the project directory taking precedence over a file in the home directory.

The .assets.json file must define as a minimum the following fields when performing global publish, alias amd import-map commands:

{

digitalsadhu

Asset Server Proposed APIs

Publishing Global dependencies

Publish a global dependency to the server:

POST /:org/:type/:name/:version

Form fields

digitalsadhu

The following lays out roughly, a proposed way to sharing dependencies across podlets.

The idea is that, through a cli tool, it will be possible to manage which libraries are available across the organisation. Here we are using react (and react-dom) as a global cross podlet dependency to illustrate the proposed workflow.

First, we publish a global version of react at a specific version. The cli tool, downloads react, converts it to esm and uploads it to the CDN at a convention based URL.

asset-pipe global publish --org finn react@16.8.6

digitalsadhu

'use strict';

class AppScaffold {
    /*
        Method used to register a plugin function that will be run in the constructor
        Plugins can be used to
            * register middleware
            * add functions to the startup queue
            * add functions to the shutdown queue
            * register metrics streams to be consumed