[web] Restructure src by creating a module per installer area#325
[web] Restructure src by creating a module per installer area#325
Conversation
dgdavid
force-pushed
the
restructure-src
branch
from
6f6c3ab to
5b354a2
Compare
To make easier writing aliases both, Webpack aliases and Jest moduleMapper, will be built from defined TypeScript paths in the tsconfig file. Read more at * https://webpack.js.org/configuration/resolve/ * https://jestjs.io/docs/configuration#modulenamemapper-objectstring-string--arraystring * https://www.typescriptlang.org/tsconfig#paths
It looks like more a "layout" than a "core" component
dgdavid
force-pushed
the
restructure-src
branch
from
5b354a2 to
0ccfbd9
Compare
dgdavid
force-pushed
the
restructure-src
branch
from
abb83b4 to
8dbf94d
Compare
dgdavid
changed the title
| * find current contact information at www.suse.com. | ||
| */ | ||
|
|
||
| export { default as LanguageSelector } from "./LanguageSelector"; |
There was a problem hiding this comment.
Maybe LanguageSelector can be named just Selector now that it is part of the language module. On the other hand, then it might or might not be imported as LanguageSelector or so in some places.
There was a problem hiding this comment.
I would do all those changes about renaming things as part of a separate PR.
| import { plainRender } from "@/test-utils"; | ||
|
|
||
| import DBusError from "./DBusError"; | ||
| import { DBusError } from "@components/layout"; |
There was a problem hiding this comment.
Maybe it is time for renaming DBusError component. What do you think?
| export { default as Layout } from "./Layout"; | ||
| export { default as Center } from "./Center"; | ||
| export { default as DBusError } from "./DBusError"; | ||
| export { default as LoadingEnvironment } from "./LoadingEnvironment"; |
There was a problem hiding this comment.
I think this is PR is a good opportunity for making LoadingEnvironment a more generic Loading component. In fact, it already receives a text prop that can be accordingly adapted too. What do you think?
| export { default as NetworkWifiStatus } from "./NetworkWifiStatus"; | ||
| export { default as NetworkWiredStatus } from "./NetworkWiredStatus"; |
There was a problem hiding this comment.
I guess we can get rid of Network prefixes now. Do you agree?
| * find current contact information at www.suse.com. | ||
| */ | ||
|
|
||
| export { default as Network } from "./Network"; |
There was a problem hiding this comment.
What about renaming this compononent to NetworkOverview. Tha way, we can go for a NetworkOverview or NetworkSummary for the summary and NetworkPage for the section page. Simlarly, we could have StorageOverview and StoragePage, LanguageOverview and LanguagePage and so on. What is more, they could be simply an Overview and Page components inside their modules...
There was a problem hiding this comment.
Yes, I vote for it: Network/Overview, Network/Page, etc. But maybe in a separate PR.
| * find current contact information at www.suse.com. | ||
| */ | ||
|
|
||
| export { default as Network } from "./Network"; |
There was a problem hiding this comment.
Yes, I vote for it: Network/Overview, Network/Page, etc. But maybe in a separate PR.
| * find current contact information at www.suse.com. | ||
| */ | ||
|
|
||
| export { default as LanguageSelector } from "./LanguageSelector"; |
There was a problem hiding this comment.
I would do all those changes about renaming things as part of a separate PR.
3 participants
Problem
As D-Installer evolves, the src directory becomes messy and out of control.
Solution
To create a module per installation area by using re-exports and to use aliases for easing the way components are imported instead of using complex relative paths.
Other interesting links