Porting from React

You do not start again. Most of a React screen converts as it is written: its layout, its text, its buttons and fields, its conditions and lists, its own small components. The rest is either a short rewrite or work that moves into your application, which on a computer with one job is where it belongs.

Measure it first

Before changing a line, ask the Screen Compiler how far your code already goes. Clone your application beside the two repositories from Screens from React, so the dev container can see it, and run the coverage report on its source:

cd nowayos-work # holds nowayos and screen-compiler
git clone https://example.com/your-app.git my-app
cd screen-compiler
make run ARGS="audit ../my-app/src"

The report reads every .tsx file under that folder and counts each construct it finds: elements, props, style properties, hooks, lists, conditions, operators and imports. Each one gets a verdict:

• in the subset: it converts, where it is used as the subset allows;
• on the road: it does not convert yet, and the report names the step that will convert it;
• out by design: it never will, and the report says why;
• unknown: the Screen Compiler does not recognise it. Unknown is never counted as converting.

Then come the steps of the road with how often each is needed, and every file with its result. A file "converts" only if check passes it, so the figure at the top is the true one. The report names constructs and never quotes your code, so it is safe to share. Like the compiler itself, run it only on code you trust.

What maps onto what

The tables on Screens from React list exactly what each component takes. They come from the Screen Compiler's own tables, so they cannot drift from what it accepts.

What moves into your application

There is no JavaScript on the device. A screen is a fixed tree that your application drives through numbered actions, fields, slots, groups and switches. So some things stay out by design, each for a reason:

• State and hooks (useState, useEffect, context). The application holds the state and sets what a screen shows.
• A field's value, checked and onChange. The application reads and sets a field through its id.
• Spread props. What they hold is known only when the code runs.
• Computed styles, colour values and global stylesheets. A style is static, colours are the theme's so the large-text theme can recolour every screen and contrast is checked, and there is no cascade.
• Animation.
• A list with no most. Slice it, .slice(0, 5), so the screen knows how many rows it may show.
• Comparisons other than a prop === a string, and if or switch in a screen's function. Work the answer out in the application and pass it as a prop.
• Components from packages, and files outside the screen's folder. A screen reads only its own folder and below: put your components beside it, ./parts/header.
• A handler that does more than call a prop. onClick={() => props.onSave()} converts; anything more is the application's work.

What the road brings next

The coverage report names these planned steps when your code needs them:

• more of CSS layout: flex growth, alignSelf, minimum and maximum heights, padding on each side, and margins;
• common HTML elements, each by one fixed rule;
• CSS modules, one class per element;
• layering: elements laid over one another;
• images and masked entry.

Until a step lands, its constructs are refused rather than guessed. Every step keeps the same rule: exact, or not at all.

Reading an error

An error gives the file, line and column, a code, what is wrong, and a line of help:

web-search.tsx:16:28: error[unknown-name]: `query` is not a prop of the component
 help: text from the application must be a prop: take it as one, function Screen({ query }) { … }

With any error, nothing is written. The codes:

When a construct you need is on the road and not yet built, say so, with the report: it shows which steps matter most.