What happens

Upon hitting the confirm() of the widget config reset, the inputs become "unfocusable" until one tabs out of the window and back in (or pressing the Windows key twice)

Steps to reproduce

1. Run client from https://github.com/wuespace/telestion-project-daedalus2/releases/tag/v0.11.2 on Windows 10
2. Log in (since this version doesn't connect to a server, no password is necessary => type any char and log in)
3. Click Profile Picture → Reset configuration
4. Click Ok (the window "reloads")
5. Try to focus / click on some text input in the login form (nothing happens)
6. Press the Windows key twice (thus, "defocusing" and "refocusing" the window)
7. Try (5.) again → now it works again

Write an action that tests the generation and build of a Telestion-Client generated PSC via the telestion-client-cli.
An example workflow could look like:

1. Setup node.
2. Install tc-cli globally.
3. Initialize a PSC.
4. Go into the PSC and build it.
5. Upload the build artifacts.

Like a "full" end-2-end test 😉

Implement the missing commands for the command line interface:

• init
• start
• build
• generate
• docs
• stats

What do you think about language support by the front-end?
Is it planned and if so, when will this be implemented? :)
If it is not planned what do you think about translations in general?

I know this is more relevant for the single subprojects however the core could already provide general functionality.

Feature Request

Summary

Add support for the new directory structure in the template-telestion-application.

Details

As described below, things we need to do in the CLI:

• Detect the core and gui/README.md folder structure. (a simple "directory exists" check should suffice)
• Delete the gui/README.md.
• Copy the template files into the guidirectory.
• Change directory into the gui folder.
• Do the rest of the initialization steps. (Install development dependencies, ...)
• Skip the git init step.
• Change the commit message to feat: Initialized Telestion Frontend (or something else)

We should probably include an else branch here to fail with a useful error message so that future breaking changes can easily be detected.

This could for example be a loading screen.
At least the name Telestion should appear somewhere in the gui, e.g. in the header, to let people know which software it is, when they see screenshots,

Document the Vert.x mock server further.
See #264 for implementation specifications.

Tools/Features that have to be updated:

• pnpm
• storybook
• prettier/pretty-quick
• husky
• chromatic
• eslint
• release-please
• jest
• fliegdoc

Parcel replacements:

• parcel
• parcel-typescript
• parcel-react

Right now, the header basically collapses for small screen widths. The Spectrum Design Guidelines do document the suggested behavior. We should align our library / components with their documentation / proposed solution.

Some aspects of the repo's README.md have become outdated.

We should probably fix wrong and improve missing information (such as missing packages in the Project Structure documentation.

Add end-to-end tests realized with Cypress

Example code to reproduce (from template):

import {
	LoginPage as TCLoginPage,
	LoginTitle,
	LoginLogo,
	LoginForm,
    LoginDescription
} from "@wuespace/telestion-client-common";

export function LoginPage(...props: any) {
	return (
		<TCLoginPage {...props}>
			<LoginLogo />
			<LoginTitle />
			<LoginDescription />
			<LoginForm initialServerURL="http://localhost:9870/bridge" />
		</TCLoginPage>
	);
}

Easiest Workaround:

Add the following line below all other code in that file:

LoginPage.routing = TCLoginPage.routing;

This needs to get adjusted in all doc comments (probably all overall usages of <LoginPage> or <TCLoginPage>), as well.

Import, adjust and document all missing resources from the old client that are still useful for the project:

• LoadingIndicator
• useDependencyTimeout

Write unit and integration tests for the Vert.x mock server.

We already have the types for our abstraction layer for widget-specific configuration. Especially for the current development in the Daedalus 2 project, it would be great if we could add its implementation soon. 😃

For the types, please see

Within the documentation of the types, there's even a small example of what we thought about how they should be used:

function ConfigControls({
  currentProps, onUpdate
}: ConfigControlsProps): ReactNode {
  // local state to not "flood" global store with changes (performance)
  const [value, setValue] = useState(currentProps.value);
  return (
    <div>
      <input type="text" value={value} onChange={event => setValue(event.target.value)} />
      <button onClick={() => onUpdate({ value })} />
    </div>
  );
}

I genuinely believe that this is the right amount of abstraction for implementing widget-specific configuration since it allows widget developers to easily add dynamically configurable properties to their widgets without sacrificing the depth of configuration options (after all, any JSONSerializable configuration can be passed to onUpdate).

Add caching mainly for the ci workflow with the actions/cache github action.
For an example, please look here:
https://github.com/actions/cache/blob/main/examples.md#node---lerna

Test all hooks in the telestion-client-core package.
Reasonable to use the @testing-library/react-hooks package to unit test their behaviour.

Clearly, the new login page system from #282 is breaking. While we missed this for the initial changelog, we should probably manually add it to the changelog.

This issue tracks the current tooling changes in the Telestion Client monorepo:

• #1374
• #1375
• #1376
• #1377
• #1395
• #1378
• #1462
• #1463

The tracking branch is: https://github.com/wuespace/telestion-client/tree/tooling-changes

After this issue is closed, the following issues/PRs are out-of-date:

• #536

In all places, usage of the login page components is documented in the following order:

<LoginTitle />
<LoginLogo />

resulting in the following look:

We should probably change that order around to

<LoginLogo />
<LoginTitle />

Post release

Things to do after the post release:

• Integrate Cypress-Dashboard
• publish fliegdoc static docs to Github Pages
• add deep-scan and CodeQL github actions
• fix and build macOS release on tags
• add branch protection rules for branch master
• move Vert.x Eventbus implementation into own repository and create own npm package
  (necessary changes in #194)

In

Because of this, we currently "abort" tc-cli build if there are linter warnings. We should probably fix that 😉

Integrate Storybook into the project to review and test React components and their behaviour.

Finish the code documentation for the telestion-client-common package to clear annoying action failures.

Fix the release workflow to be conform with the maintainer documentation for this project.
We need to test publishing in GitHub Actions via an NPM_TOKEN secret.

E.g. 9-DOF sensor

Cf. https://602b11ba9b6ce700236536da-ehsiqkblwz.chromatic.com/?path=/docs/common-header-dashboard-picker--simple-dashboard-picker

Expected behavior

When logging in and loading the initial dashboard, the selector should have that dashboard selected.

Actual behavior

The user needs to select some dashboard first manually. After that, the behavior is correct.

^

Extend the mock server to support integration testing.

Useful functionalities:

• Function to send messages and reply to received messages
• Hooks to intercept receiving and sending messages
• Hooks to intercept specific types of messages, manipulate them
• "Message store" which holds all received and sent messages and which is clearable via a function
• exposure of the sockjs and http server instance

Ideas and suggestions are welcome 😉

A list of dependencies which are currently on hold/ignored by Dependabot:

• #512
• #517
• #1004

Widgets, when generated, get added to the src/widgets/index.ts as their "source" type.

This, however, creates a type error if they extend Widget<SomeConfig> instead of Widget.

We should add them to the src/widgets/index.ts with an as Widget appendix to avoid this.

A mode which allows the creation and modification of dashboards in the common package.
Something like card a drag-and-drop editor and size manipulation.

When in the first text field, go to the second, then third, and so on. On the final field, press the login button.

Please update the Storybook packages/components and their configuration.
Some parts of storybook have changed drastically, e.g. Create React App is now in a separate thread and the default PostCSS plugin is deprecated.

Some possible improvements for the widget renderer in the next version:

• allow reset of widget in config controls
• store version of widget in persistent config to allow checks for breaking changes

Within the planning stages of these libraries, we had already planned to support a generic way of declaring application preferences (as part of our core structure) which could, then, be used to allow Project-Specific-Client developers to easily add app-global settings that could still get rendered into one, unified (though grouped) settings page.

Here's an example of how using these APIs might look like:

            <Preferences>
                <Group name="Bildübertragungseinsetllungen">
                    <Variable key="Kameraname 1">
                    {
                        (val, setVal) => 
                            <input value={val} onChange={setVal} />
                    }
                    </Variable>
                    <Variable key="Kameraname 2">
                    {
                        (val, setVal) => 
                            <input value={val} onChange={setVal} />
                    }
                    </Variable>
                </Group>
            </Preferences>

As with #562, the goal is to provide a unified way of having preferences (in this case, application-wide), without losing the option of complexity, which is why every variable can be "as complex" as it needs to be (just pass a complex JSONSerializable object to setVal).

Still, everything rendered by this renderer can be put into the right spot (e.g., depending on the implementation, a unified settings page).

All in all, I believe that this approach provides both ease of use as well as the right amount of versatility. For really complex endeavors, of course, PSCs can still implement their own, individual, settings pages, but the combination of #562 and this should probably cover ~ 97 % of cases 😉

Why put it into the core, though?

While an implementation for a unified settings page should be put into common, the settings structure, by itself, is abstract and independent from the framework used (as long as React is used). This means that the components belonging to the overall concept (registering these messages, making them accessible in the application, etc.), by our definition, belong into core, since they could, just as well (with different implementations of the VariableRenderers, of course) be used in, e.g., React Native.

This idea's components that probably fit into common are "just"

• A unified settings page that renders the overall layout of the settings page
• Common Variable components (e.g., TextInputVariable) which cover the most typical variable types (text, number, color, ...)

References

https://github.com/wuespace/telestion-client/blob/28a85e8359b4f127a1bd956c9a14184d36e59034/packages/telestion-client-types/src/preferences.ts

https://github.com/wuespace/telestion-client/tree/ba323b41810aafc6df263899dac7d9ac7df597c9/packages/telestion-client-core/src/components/preferences

The generated package.json for PSCs misses the "eslintConfig" field.

This results in a few weird behaviors when, e.g., using certain Typescript features (like Indexed Access Types).

To fix this, we need to add an eslintConfig field to the package.json. I suggest keeping to the CRA-template, meaning we'll need to add the following:

  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },

Write unit and integration tests for the Vert.x EventBus.
Reasonable to use the Vert.x mock server.
See #264 for mock server implementation status.

Currently, the <LoginDescription /> component produces a type error when added as a child of import('@wuespace/telestion-client-common').LoginPage:

$ tsc --noEmit
src/components/login-page.tsx:14:5 - error TS2786: 'LoginDescription' cannot be used as a JSX component.
  Its return type 'Element | ReactElement<any, string | ((props: any) => ReactElement<any, any> | null) | (new (props: any) => Component<any, any, any>
)>[]' is not a valid JSX element.
    Type 'ReactElement<any, string | ((props: any) => ReactElement<any, any> | null) | (new (props: any) => Component<any, any, any>)>[]' is missing th
e following properties from type 'Element': type, props, key

14              <LoginDescription />
                 ~~~~~~~~~~~~~~~~


Found 1 error.

The project still runs using tc-cli start, but, of course, the error is, still, annoying.

This issue also occurs in the RocketSound PSC: https://github.com/TelestionTeam/telestion-daedalus2-psc/tree/e36c0a614132235945141ba4cc147f0e74628356

Add an event bus debug widget for easier connection state inspection and bug fixing.
An implementation could look like:

Well, we have a notification store in the core package, but no implementation on the common side to display the notifications. 🙈

I think, we should change that!

See https://whatwebcando.today/local-notifications.html

Feature Request

Summary

Optional GitHub Actions on tc-cli init

Details

Can we give the template some predefined GitHub Actions and ask on initialization to install those in the generated PSC git repo?

For example:

Would you like to install predefined GitHub Actions?
> (yes/no)

These predefined GitHub Actions are already in these repositories:

• https://github.com/fussel178/telestion-rocketsound/tree/feat/merge-with-psc/.github/workflows
• https://github.com/wuespace/telestion-rocketsound-psc/tree/main/.github/workflows

Test all hooks in the telestion-client-common package.
Reasonable to use the @testing-library/react-hooks package to unit test their behaviour.

Anyone know how reliably test a command line interface like the telestion-client-cli?
Suggestions are welcome 😉