croz-ltd / nrich-frontend Goto Github PK

Basic information

Add licence header to all source files

Additional information

Enhancement description

At the moment, source files don't contain licence header, take a look at e.g. Spring where it's present.

Current behaviour

There are no licence headers in any source files.

Wanted behaviour

There should be same licence header in all source files.

Possible workarounds

Basic information

A main GitHub Action for building the project is needed.

Additional information

See nrich for an example script. Note: that one is a Java project.

Enhancement description

The script should run tests as part of the build.

Current behaviour

No GitHub action present.

Wanted behaviour

Main "build" GitHub action present.

Possible workarounds

Basic information

• nrich-demo-frontend version:
• Module: nrich-notification-core

Additional information

Bug description

With the latest nrich update, a new property called timestamp was provided from the backend in order to track the notification with a unique property value in the notification store. However, the timestamp property is treated like a string a needs to be cast to a Date in order to support the usage of Date-related functions in the codebase of the nrich-notification-core module.

Steps to reproduce

Attempt to call any backend endpoint for notifications from the notification demo.

Expected behavior

The notifications should be displayed correctly using the UI module.

Actual behavior

The notifications are not displayed using the UI module.

Basic information

• nrich-demo-frontend version: 0.0.3 (only nrich/form-configuration-core is used)
• Module: nrich-form-configuration

Additional information

yup version: 0.28.5

Enhancement description

When backend validation does not specify that field has to be @NotNull or @NotBlank then include .nullable() when generating yup schema for that field.

Current behaviour

Current behaviour is that the generated yup schemas expect that every field is not nullable, which is quite problematic when these fields can actually be null. For instance, when updating an entity values returned from the backend for some fields are null (instead of undefined) and this registers as invalid when it is not.

Wanted behaviour

Fields that are nullable should accept null value.

Possible workarounds

A override schema can be added that overrides the generated schema with nullable value, but this brings additional confusion with validation.

Basic information

Add code coverage integration with codecov.io.

Additional information

See nrich for example. Note: that one is a Java project.

Enhancement description

Add code coverage integration with codecov.io so we can have a graphic representation of the code coverage. Add test report generation and publishing to the main "build" GitHub Action.

Current behaviour

No integration with codecov.io.

Wanted behaviour

Integration with codecov.io present.

Possible workarounds

Basic information

• nrich-demo-frontend version: 0.0.2
• Module: form-configuration

Additional information

Currently, url is required parameter of FormConfigurationProvider. On backend, there is a default url (/nrich/form/configuration) which users will rarely change. To prevent every project to have to define this parameter, a default could be added.

Current behaviour

url must be specified every time FormConfigurationProvider is used.

Wanted behaviour

Url should not be required prop.

Possible workarounds

To add an url :)

Basic information

Align line endings for all files to eslint config.

Additional information

Enhancement description

Line endings are not aligned in all files. Eslintrc needs to be updated to match editorconfig and unaligned files should be updated.

Current behaviour

Files are not aligned with eslint.

Wanted behaviour

All files use LF for line endings and eslint configuration reflects that

Possible workarounds

Basic information

Add open source license to GitHub project.

Additional information

See nrich for example. There, we used Apache License 2.0, so, we suggest using it here as well.

Enhancement description

Add open source license to GitHub project before it becomes public.

Current behaviour

No open source license present.

Wanted behaviour

Open source license applied.

Possible workarounds

Basic information

Change type of FormConfigurationConfiguration.requestOptionsResolver

• Module:
  libs/form-configuration-core

Additional information

Enhancement description

Change type of FormConfigurationConfiguration.requestOptionsResolver from () => Record<string, string> to () => RequestInit.
This change allows for a type safe way of defining additional configuration options to send with the fetch request.

Current behaviour

With the current type Record<string, string> it isn't possible to add authentication information to the fetch request.
I tried using { "headers.Authorization": "Bearer token" } which does not work.

Wanted behaviour

With the type being RequestInit the following would be valid:

{ 
    headers: {
        Authorization: "Bearer token",
    }
}

Possible workarounds

Abusing the as operator to change the type to any as shown below.

function Demo() {
    const getRequestParams = (): RequestInit => ({
      headers: {
        Authorization: "Bearer token",
      },
    });

    return (
        <FormConfigurationProvider 
            url="/nrich/form/configuration" 
            requestOptionsResolver={getRequestParams as () => any}
        >
            {...}
        </FormConfigurationProvider>
    );
}

Basic information

• nrich-demo-frontend version: 1.0.0
• Module: all

Additional information

Enhancement description

In order to simplify semantic versioning, consider using Changesets, along with Changesets GitHub Action.
This will ensure that the modules are properly versioned, and will force the user to increase the version if something has changed in the source code. Alongside that, the GitHub Action will open a PR with relevant version changes each time a push has been made to the master branch. Once that PR is merged, the modules will be published to the NPM registry.

Current behaviour

Manual versioning.

Wanted behaviour

Automatic versioning of modules.

Possible workarounds

Basic information

• nrich-demo-frontend version:
• Module:

Additional information

Enhancement description

Considering the increasing complexity of maintaining custom build scripts, it would be wise to move to something more easily scalable, such as a build management system like Turborepo.
This would enable us to more efficiently build "pipelines" which would propagate across all of the lib workspaces, consequently decreasing command run times.

Current behaviour

Custom build scripts are applied to be able to build all of the workspaces.

Wanted behaviour

Integrate Turborepo into the repository and delete old build scripts, along with abstractingrelevant common configs to separate workspaces.

Possible workarounds

Basic information

• nrich-frontend version: 2.0.0
• Module: form-configuration-core

Enhancement description

Currently, useYupFormConfiguration hook returns ObjectSchema<any>. This should be extended to provide option to use generics when user has defined type for validated form.
This could be mostly beneficial when used together with strongly typed form libraries, like react-hook-form

Current behaviour

useYupFormConfiguration hook returns ObjectSchema<any>

Wanted behaviour

type RegistrationForm = {
  username: string,
  password: string,
};
const configuration = useYupFormConfiguration<RegistrationForm>(formId); // returns ObjectSchema<RegistrationForm>

Possible workarounds

Casting via unknown, but that is big code smell.

const configuration = useYupFormConfiguration(formId) as unknown as ObjectSchema<RegistrationForm>

Basic information

• nrich-demo-frontend version: 0.0.2
• Module: project

Additional information

Add more extensive documentation for the notification and form-configuration modules, with short example of usage

Current behaviour

Documentation in Readme.mds does not exist for specific modules.

Wanted behaviour

Documentation in Readme.mds does exist for specific modules.

Basic information

• nrich-frontend version: 1.0.9.
• Module: form-configuration-core, notification-mui

Bug description

Tests show warnings when using renderHook method as the @testing-library/react-hooks is not compatible with React 18. renderHook method was migrated to @testing-library/react but without error field, which is used in useYupFormConfiguration test.
This points to a flaw in useYupFormConfiguration where nrich throws an error when called with non-existing formId. To handle that, user should wrap that hook use in try-catch, which breakes the rules of hooks.

API should be changed so useYupFormConfiguration returns undefined on non-existing formId so it could be used without breaking the rules of hooks.

Steps to reproduce

Visible when running should throw error for unknown formId in use-form-configuration.test.ts.

Expected behavior

For test to run without warning and for API to not throw error.

Actual behavior

Tests have warning for React 18, and API throws an error.

Basic information

Add ADR template and decisions.

Additional information

See nrich for example.

Enhancement description

We would like a way of tracking our architecture decisions in the project as to make onboarding of new developers easier
and keep track of important changes inside the project.

Current behaviour

No explanation of the current architecture exists.

Wanted behaviour

A list of architecture decision records exists explaining the current state of project. All future decisions are also recorded.

Possible workarounds

Basic information

Define branch protection and pull request rules after the repo becomes public.

Additional information

Configure same settings as in nrich.

Enhancement description

Define and add

• branch protection rules
• pull request rules (rebasing, build has to pass, min. 1 approval etc.)

Current behaviour

No branch protection nor pull request rules present.

Wanted behaviour

Branch protection and pull request rules present.

Possible workarounds

Basic information

• nrich-demo-frontend version: 1.0.0
• Module: all

Additional information

Enhancement description

Support generating documentation from TSDoc in form HTML and deploy it to GitHub Pages in the execution of the build workflow on the master branch.

Current behaviour

No documentation is being generated and/or deployed to GitHub Pages.

Wanted behaviour

Generate and deploy HTML documentation to GitHub Pages.

Possible workarounds

Basic information

• nrich-frontend version: 1.0.9
• Module: project

Additional information

Vite environment, Typescript

Bug description

When using Vite, nrich dependency must be imported from dist. This is problematic because most IDEs will auto-import from root.
Also, it is a runtime error, not compiletime.

Steps to reproduce

1. Create a bare Vite project
2. Add any nrich-frontend dependency, eg. @croz/nrich-notification-core
3. Add import, eg. import { useNotifications } from "@croz/nrich-notification-core";
4. Run Vite

Expected behavior

No errors

Actual behavior

Error for import.

Potential workaround

Use import from dist: import { useNotifications } from "@croz/nrich-notification-core/dist";

Basic information

• nrich-frontend version: 1.0.9
• Module: nrich-registry

Enhancement description

Create nrich-registry module as frontend part of nrich-registry.
The module should have simple API to create tables and forms for searching, creating, updating and deleting registry entries..

Current behaviour

The module does not exist.

Basic information

Add missing GitHub templates/items in the Community Standards.

Additional information

Take a look at the configured templates in nrich and add them analogously.

Enhancement description

Add missing GitHub templates/items in the Community Standards when the project becomes public.

• Code of conduct
• Contributing guidelines
• Issue templates
• Pull Request template
• other?

Current behaviour

There are missing GitHub templates in the Community Standards.

Wanted behaviour

There are no missing items in the GitHub Community Standards.

Possible workarounds

Basic information

Add GitHub badges to main README.md.

Additional information

See nrich for example.

Enhancement description

Add badges for the "build" GitHub Action, for the open source license and for codecov.

Current behaviour

No GitHub badges in main README.md.

Wanted behaviour

GitHub badges added to main README.md.

Possible workarounds

Basic information

• nrich-frontend version: 3.0.1
• Module: notification

Enhancement description

Currently the only way to use the notifications API is via the useNotifications hook. There are instances where we need just standard JS functions to satisfy the React naming conventions and linters. One such example is using the notifications with API calls or related interceptors which are not a hook or part of a React component.

As-is, the current logic would work even outside of React components, so it's basically only required to re-export under a different naming convention.