Context

As far as we thought about this application we known that it should work with two pre-requisites:

1. Have persistent data

but also

2. Work without a backend

Those requisites has a lot in common with the local-first web development pattern and we want to proceed in that way.

We couldn't say if in the future we could implement a proper backend server, but for the moment this app should work as stand alone with local persistent data shared between the browser session with some kind of technology.

Proposed solution

One of the most used technologies is RxDB which allow the application to store the data in a offline database with the possibility to syncronize the data with some custom endpoint or download it in a json as well.

I already tested this library with a PoC inside the develop branch.

The documentation is pretty good but there are some inconguences through the versions and some missing useful examples.

Alternatives

Alternativelly, we could going though with two different libraries:

• PouchDB
• TinyBase

ATM Comments type is

export type TCommentDynamicData = {
  username: string;
  content: string;
};

export type TComment = {
  id: string;
  caseId: TCase["id"];
  testId?: TTest["id"];
  stepId?: TStep["id"];
  createdAt: number;
  testStatusWhenCreated?: StatusEnum;
  resolved: boolean;
} & TCommentDynamicData;

This way we cannot easily use the Avatars component to show the user's Avatar (in comments list, for example).

We could change it into something like :

export type TCommentDynamicData = {
  collaboratorId: string;
  content: string;
};

We should think about this application as an offline application that work locally without any persistent data stored online.
This choice was made in due to the fact that this app should be straightforward and work as stand alone application without a backend that syncronize the data.

This issue was open to setup the application properties in order to make it works as an PWA.

• Work with persistent offline data
• Focus on performance
• Offline data and asset

https://web.dev/learn/pwa/
https://www.halo-lab.com/blog/react-pwa-tutorial-how-to-create-progressive-web-app-with-react

When selecting a Test/TestCase with no description, if a description was already set on the previous Test/TestCase, the component won't update correctly

• on comment list delete
• on steps delete

Once the UI Kit is chosen we need to start to disassemble the static mockup building the UI common components as button, tables, views, link, ecc...

Each component shouldn't used directly from the UI Kit but it should be wrapper inside a custom component with some props in order to customize it.

Also, we need to implement a storybook library in order to document the component as stand alone.

Is not possible to edit form values while on editing mode

Add infos to the exported JSON, and adapt its import.

• network server url
• automerge repo url/ID

Add infos to repository:

• title
• description

Should be edited in the "home" section

Those should be exported and imported via JSON

• plain json
• https://github.com/pubkey/rxdb
• https://pouchdb.com
• https://github.com/Nozbe/WatermelonDB
• https://github.com/techfort/LokiJS
• https://github.com/typicode/lowdb

We opted for https://github.com/pubkey/rxdb

Seems to not being showed at the moment

Once the UI Kit is chosen we need to focus to implement the main layout of the application and then start to think about the navigation between the pages.

https://mantine.dev/

Context

We need a strong and consinstent library in order to build our application which allow us to customize and build the layout without any complication. The library should be complete with the possibility to customize in an easy way each part of the layout and the theme.

Proposed solutions

A pretty good UI Kit for this Application could be Mantine which I already used on this project to build the PoC in the develop branch.

I think that one of his stringest point is the "Mantine Hooks" that this UI Kit provides in order to abstract the theme logic. Also, the library includes a feature in order to handle the forms logic (they have done an excellent job here) with mantine hooks and components.

The library has a good and strong documentation with a lot of examples and explanations.

Alternatives

We could think to use Ant Design or Material UI.

It could be used for planning and reporting.
https://frappe.io/gantt

Dependencies: #10

The section page should show a list of members (users) that has "in charge" the conducting of tests. The users has only the job to be listed inside the Test details, there is no authentication logic behind this.

This page should has the same layout of the Use Cases page (title, table, new item, ecc...) with the possibility to: browser the users, add a new member and see his details.

https://ajv.js.org/

By clicking on the title's text an input should be shown for a quick text edit

Add filters in overview sidebar and handle the show/hide of the tasks table elements

Selects also have a custom dropdown style

Ok electron

Create a form where is possible to set the automerge server url.

It should be possible to set an empty value showing it as a "use yTestbook offline" option.

This "automerge server url" value should be also set in LOCAL_STORAGE.

Show a relative time label like "3 months ago", "10 minutes ago".

Check for:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/RelativeTimeFormat#try_it

Add buttons should add an inline row at the bottom of the table.

This is valid for tasks, subtasks and steps.

The title would be enough for a new item creation.

More details of the task/subtask should be added inside the content details.

When adding more comments in a row, some data about the author will be lost. This bug is also in the staging release.

Add sidebar showing Step details.

As I was saying in this PR it's usually better to handle modals imperatively through Mantine's Modal Manager.

This allows to:

• keep the flow of the events, making it easier to debug for everyone by avoiding using effects
• improve the callback handlers
  • modals are opened in the button's onClick/handler, and params can be passed directly from the list instead of having to save and rerender the whole component
• avoid reinventing the wheel for every modal
  • e.g. having to add a piece of state just to know if the modal is opened or closed

IMO, this behavior should be used for ALL the modals, whether they are confirm modals or not

For example, when adding TestCases inline, pressing the Tab key should also save the values (like the Enter key does)

The same behaviour should occurr (maybe ?) also when clicking outside (before hiding the form)

Esc key is actually closing the form WITHOUT saving (and that's OK)

This was reported to me by @ebordoni