wuespace / telestion-client Goto Github PK
View Code? Open in Web Editor NEWTelestion Frontend Framework (Technical leads: Ludwig Richter, Jan Tischhöfer)
Home Page: https://telestion.wuespace.de
License: MIT License
Telestion Frontend Framework (Technical leads: Ludwig Richter, Jan Tischhöfer)
Home Page: https://telestion.wuespace.de
License: MIT License
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.
In
'Compiled successfully'
. However, if there are linter warnings, this instead reads as 'Compiled with warnings'
(or something similar).
Because of this, we currently "abort" tc-cli build
if there are linter warnings. We should probably fix that 😉
Test all hooks in the telestion-client-common package.
Reasonable to use the @testing-library/react-hooks package to unit test their behaviour.
Things to do after the post release:
master
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.
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"
]
},
Document the Vert.x mock server further.
See #264 for implementation specifications.
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.
Add end-to-end tests realized with Cypress
Test all hooks in the telestion-client-core package.
Reasonable to use the @testing-library/react-hooks package to unit test their behaviour.
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
Some possible improvements for the widget renderer in the next version:
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:
tc-cli
globally.Like a "full" end-2-end test 😉
^
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!
Optional GitHub Actions on tc-cli init
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:
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 😉
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"
TextInputVariable
) which cover the most typical variable types (text, number, color, ...)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.
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
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.
We should probably include an else
branch here to fail with a useful error message so that future breaking changes can easily be detected.
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
).
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.
Anyone know how reliably test a command line interface like the telestion-client-cli?
Suggestions are welcome 😉
Add support for the new directory structure in the template-telestion-application.
As described below, things we need to do in the CLI:
core
and gui/README.md
folder structure. (a simple "directory exists" check should suffice)gui/README.md
.gui
directory.gui
folder.git init
step.feat: Initialized Telestion Frontend
(or something else)Integrate Storybook into the project to review and test React components and their behaviour.
Import, adjust and document all missing resources from the old client that are still useful for the project:
When in the first text field, go to the second, then third, and so on. On the final field, press the login button.
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.
Implement the missing commands for the command line interface:
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.
Data | Value |
---|---|
Affected versions | >=0.6.0 |
Write unit and integration tests for the Vert.x mock server.
Tools/Features that have to be updated:
Parcel replacements:
E.g. 9-DOF sensor
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,
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.
When logging in and loading the initial dashboard, the selector should have that dashboard selected.
The user needs to select some dashboard first manually. After that, the behavior is correct.
Extend the mock server to support integration testing.
Ideas and suggestions are welcome 😉
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.
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)
Finish the code documentation for the telestion-client-common package to clear annoying action failures.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.