You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue:
Forklift UI pages are designed for stand alone application, some features and optimizations are geared to take full advantage of strengths and weaknesses of this architecture.
Moving forward to using openshift SDK [1] inside the console [2] we need to adjust both visual look, and coding patterns. We should leverage as much as possible the capabilities of the SDK, and align our visual appearance, coding patterns and design goals with the console.
Console design goals [ from console github page [2]]:
The console is a more friendly kubectl in the form of a single page webapp. It also integrates with other services like monitoring...
Unlike the forklift-ui whose goal is to provide easy to use UI, the console main agenda is to stick to what kubectl can do.
For example:
"educate users": a user can go to the web-console, learn how to create the provider secret and resource, and then using this knowledge, continue and create gitOps or other automation.
"easier to use kubectl": users the want to create a migration plan will have a nice form, that will guide them, instead of having to write the YAML.
Visual aspect
The forklift-ui is visually different then the console, although both use patternfly [3] they differ in table design and single resource view/edit pages.
Moving forward to a plugin look, we want to align better with the console look, for example: using single resource pages, instead of the "edit" modal the forklift ui is using.
Coding patterns
forkilift-ui by design integrate it's own "fetch/cache/mutate" client that influence the code design to use context patterns, where we use {wrapper { consumer} }. the console approach is using hooks that influence the design to be a fetch->mutate->render flow, as a plugin in the console ecosystem we should adept to using the hook approach.
Issue:
Forklift UI pages are designed for stand alone application, some features and optimizations are geared to take full advantage of strengths and weaknesses of this architecture.
Moving forward to using openshift SDK [1] inside the console [2] we need to adjust both visual look, and coding patterns. We should leverage as much as possible the capabilities of the SDK, and align our visual appearance, coding patterns and design goals with the console.
Console design goals [ from console github page [2]]:
Unlike the forklift-ui whose goal is to provide easy to use UI, the console main agenda is to stick to what
kubectl
can do.For example:
"educate users": a user can go to the web-console, learn how to create the provider secret and resource, and then using this knowledge, continue and create gitOps or other automation.
"easier to use kubectl": users the want to create a migration plan will have a nice form, that will guide them, instead of having to write the YAML.
Visual aspect
The forklift-ui is visually different then the console, although both use patternfly [3] they differ in table design and single resource view/edit pages.
Moving forward to a plugin look, we want to align better with the console look, for example: using single resource pages, instead of the "edit" modal the forklift ui is using.
Coding patterns
forkilift-ui by design integrate it's own "fetch/cache/mutate" client that influence the code design to use context patterns, where we use
{wrapper { consumer} }
. the console approach is usinghooks
that influence the design to be afetch->mutate->render
flow, as a plugin in the console ecosystem we should adept to using thehook
approach.[1] https://github.com/openshift/dynamic-plugin-sdk
[2] https://github.com/openshift/console
[3] https://www.patternfly.org/v4/
References:
Console coding examples:
https://github.com/openshift/console/blob/e65c93b383d067f6fa2834880721b83e4bc1c0bd/frontend/public/components/pod.tsx#L967
https://github.com/openshift/console/blob/master/dynamic-demo-plugin/src/components/ListPage.tsx
https://github.com/openshift/console/blob/e65c93b383d067f6fa2834880721b83e4bc1c0bd/frontend/packages/kubevirt-plugin/src/components/cdi-upload-provider/upload-pvc-form/upload-pvc-form.tsx#L82
Console visual examples:
The text was updated successfully, but these errors were encountered: