The way of adding top level screens as a list to the props and the actions in frets-starter is pretty clean, but some of it could be brought into the main frets library as an optional module.

Something like:

import {registerNavigation} from "frets"


export interface IRouteKeys {
  About: SampleScreens;
  Home: SampleScreens;
  Users: SampleScreens;
}

export const routeKeys: IKeyObject = {
  Home: "/home",
  Users: "/users",
  About: "/about",
};

F = registerNavigation<MyProps, MyActions>(myApp, routeKeys)

In order to save on final compiled bundle size the generated classes based on the CSS files should be circumvented after the developer is done using them for writing. A webpack loader might be able to look at the long function chains and use regex to convert them back into a static hyperscript declaration like h("div.bold.mx-2.p-2") the typescript classes are super useful for writing and linting, but add a couple kilobytes of code to the final bundle just for developer ergonomics .

I have considered switching to CSS Modules but am not sure it will really be helpful since the webpack css-loader is built for replacing values in a class attribute with a specifically scoped hashed version.

Pseudo code:

1. loader function is passed the source of a typescript file
2. check for existence of an import of a generated atomic stylesheet class

• this relies on consistent use of a naming convention like import $$ from "./base-styles" so anything that start with import {$, $$ is a style class import

3. regex match any code string that starts with $$( or $. and ends with .h(
4. each match should be converted so that dots are spaces, and camelCased symbols are converted to hyphen-cased - basically the inverse of what the frets-styles-generator does to create the typescript class members
5. remove the reference to the style class import
6. add a import { h } from "maquette" (if it doesn't already exist)

• Summary
  If we could use other html rendering and VDom implementations it would make this library more flexible and reusable. Integrated with other communities. Maybe as a first pass we see if it's possible to refactor the rendering functions to support switching to https://redom.js.org/. Another super-light-weight dom library.

I want it to be possible to register new functionality in a simple developer friendly and async way.

Developers should be able to include a UI rendering function that takes an instance of the FRETS class and enhance it with it's own necessary actions, data properties, and calculation and validation functionality.

Approach: Add a third parameter to the standard UI rendering function signature, an instance of the FRETS class. When a plugin needs to be registered, all of it's action methods are added to the actions of the FRETS instance. A calculate function can be patched with a new function (maybe one that calls next() at the end?). The validate function can be patched in the same way. The data properties class can be extended with additional properties. When the App is extended with this plugin the extend/register function should return a new instance of the props and the actions classes so that developers still get great intellisense and strong typing when accessing "actions" or "props" internally.

Research this approach: https://hapijs.com/tutorials/plugins

Things to avoid:

• adding internal state to the rendering function which is expected to persist between renders.
• making the developer remember if something is available on the props or actions through magic strings or magic property names that can't be hinted from the IDE.

https://blog.sindresorhus.com/ava-1-0-861d780b2d81

TypeScript support from this recipe? https://github.com/avajs/ava/blob/master/docs/recipes/typescript.md

This should greatly simplify testing scripts but might slow the tests down because of the loss of compileEnhancements ?

• I'm submitting a ...
  [ ] bug report
  [x] feature request
  [ ] question about the decisions made in the repository
  [ ] question about how to use this project

• Summary
  When an async promise is resolved its necessary to call F.render(props) and this means there is a chance that old state props will be sent into the app. A patch method that just overwrites a portion of the main props object would avoid this problem.

Inspired by the documentation on tao.js.org I am re-considering the validator flow. A rendering method should be able to register interceptors for validation. If an interceptor returns a falsy value then execution continues, if it returns any value that value is treated as a new context for the state to calculate.

Users who write rendering functions should be able to create adhoc state calculations as well. They should be registered in the main app and they just affect values in their own purview, some key perhaps that identifies the terms to be calculated and affected.

...

A smaller and easier to read introduction is needed for the main README. Currently, it doesn't do a good job of easing new users into the library.

I've switched to using the new FRETS class which allows developers to build up the app in a more readable and easy to parse set of functions and assignments like:

• registerAction(...)
• registerView(...)
• calculator = ...
• validator = ...

I would like to deprecate the old Classes including:

• App
• AppBuilder
• AppConfiguration
• Actions
• Model
• State
• View
• ComponentMap

My idea is to target them to be gone in 1.0

This would allow enforcement of stricter code coverage rules.

When a developer is building a form they find themselves wanting to update state to match whatever is in a HTML Input element value all the time. Developers need an easy way to generate simple state update action functions like the following in a non-repetetive way... preferrably without magic strings.

F.actions.setName = F.registerAction((e: Event, props: AppProps): AppProps => {
  props.customerName = (e.target as HTMLInputElement).value;
  return props;
});

But it would looks something like this when implemented:

$.input.h({ 
  name: "email" 
  value: props.email,
  onchange: actions.getInputUpdater("email"),
}),