xbyorange / react-mercury Goto Github PK

Migrate project from gitlab private repository and publish it into NPM public registry.

The structure of the code inside the demo folder does not fully accomplish with the @XbyOrange front end architecture guidelines. As this demo is very useful as an introduction to the architecture for new developers, it should follow the architecture guidelines exactly.

Then, it is desirable to change the structure of the code to make it compliant with the company front-end good practices.

Dependencies should be upgraded to fix the potential security vulnerability reported by github:

Upgrade bl to version 0.9.5 or later

An npm error is returned when trying to install dependencies inside "demo" folder.

It is probably related to an issue in the package-lock.json file.

This issue has been reported by @juanmagit, who maybe can apport more details about the operating system, nodejs and npm versions in which it was experimented.

To release version 1.1.0 stable version it is necessary to complete next tasks:

• Develop unit tests to achieve 100% of coverage.
• Increase coverage thresholds to 100% again.
• Write server side data documentation, and examples.
• Enable coveralls command in CI.

When using Mercury in projects with server side render, it should be useful to provide an initial data to Mercury sources. The connect function should return the server side data until client-side data finish loading, and meanwhile, it should return loading property as false.
Server side data loading should be able to be disabled.

Module index.js files are usually exporting resources this way:

import { MainRouter } from "./routers/main"; export default MainRouter;

With alternative methods like:

export { MainRouter } from "./routers/main";

or:

import { MainRouter } from "./routers/main"; export { MainRouter };

the plugin crashes when executing the rules factory avoidMultipleExportsInSubPiece:

TypeError: Cannot read property 'type' of null Occurred while linting /home/juan/Documents/workspaces/ORANGE/react-mercury/demo/src/modules/books/index.js:6 at checkExportType (/home/juan/Documents/workspaces/ORANGE/react-mercury/demo/node_modules/@nex/eslint-plugin-modular-react/lib/rules-factories/avoidMultipleExportsInSubPiece.js:44:30) at checkDeclarations (/home/juan/Documents/workspaces/ORANGE/react-mercury/demo/node_modules/@nex/eslint-plugin-modular-react/lib/rules-factories/avoidMultipleExportsInSubPiece.js:55:9) at listeners.(anonymous function).forEach.listener (/home/juan/Documents/workspaces/ORANGE/react-mercury/demo/node_modules/eslint/lib/util/safe-emitter.js:45:58) at Array.forEach (<anonymous>) at Object.emit (/home/juan/Documents/workspaces/ORANGE/react-mercury/demo/node_modules/eslint/lib/util/safe-emitter.js:45:38) at NodeEventGenerator.applySelector (/home/juan/Documents/workspaces/ORANGE/react-mercury/demo/node_modules/eslint/lib/util/node-event-generator.js:251:26) at NodeEventGenerator.applySelectors (/home/juan/Documents/workspaces/ORANGE/react-mercury/demo/node_modules/eslint/lib/util/node-event-generator.js:280:22) at NodeEventGenerator.enterNode (/home/juan/Documents/workspaces/ORANGE/react-mercury/demo/node_modules/eslint/lib/util/node-event-generator.js:294:14) at CodePathAnalyzer.enterNode (/home/juan/Documents/workspaces/ORANGE/react-mercury/demo/node_modules/eslint/lib/code-path-analysis/code-path-analyzer.js:632:23) at nodeQueue.forEach.traversalInfo (/home/juan/Documents/workspaces/ORANGE/react-mercury/demo/node_modules/eslint/lib/linter.js:752:32)

The demo application should have unit tests. Doing this, it could be used as a guideline for the unit tests development implying mercury libraries.
The demo unit tests should be executed in the pipeline too.

Currently serverSideData of a mercury source is not being properly identified during client side execution. It is probably related with the identifier being generated for mercury sources instances, which is not enough consistant from server side to render side.

It is needed to improve the process of generating mercury instances unique identifiers.

In some scenarios, the "readServerSide" method is throwing a "duplicated id" error even when the source id is a custom uuid and it is not duplicated.

It occurs in Next.js applications, when the page is refreshed. It seems that Next.js is "reloading" some js resources while keep another ones in memory. So, probably, the same "source" is being added to be "read on server side" more than once.

This Next.js behavior is hard to solve, so maybe the best solution should be to not throw an error, but to trace a warning instead.

Currently, the examples of mercury use cases in the demo application don't cover complex cases and new mercury features. It is desirable to add more examples of how the library can be used to solve complex behaviors.

Some of the features should include use cases related to a...

• Selector querying dinamically a source, based on its own query.
• Selector returning another selector or origin.
• Selector querying a source based on previous source results.
• Selector reading sources in parallel.
• Selector catching a source error and returning a fixed value when it happens.
• Selector catching a source error and returning another source when it happens.

Sonar has reported some code smells in the demo code.

https://sonarcloud.io/dashboard?id=xbyorange-react-mercury

It is desirable to fix them. No new release is necessary, because demo code is not published to NPM.