Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement: Design better module dependency handling #852
Enhancement: Design better module dependency handling #852
Changes from all commits
d12dac5
e4ff7b5
da1d58e
531b20b
5f85e27
c029382
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our next step (in other PR) can be extracting all the code where we check
isModuleEnabled(module)
into separate files. It should improve the code maintenance and reduce number of merge conflicts. I can imagine if a customer does some customization on pipelines and has to rebase and merge conflicts with a new dataset changes from main since everything in the same file :)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I understood you, you mean as components created in the module folder that are imported into the environment view? My idea for this view was to define this particular block in a more abstract way. Instead of hardcoding the different environment modules, I would prefer to have some sort of logic that creates the blocks based on the information in the index files + config activation status of the modules. But looking at it now i think we can combine both approaches:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can create a new issue for this particular problem + review if we can move some of the current code from
frontend/services
intofrontend/modules/MODULENAME/services
given that we define the dependencies well. Based on feedback from customers, I will also propose to create another directoryfrontend/core/
where we place modules such as Environment. Wdyt? Does this make sense or is it against frontend design rules?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good idea.
I believe it's a good idea to consider which worth it's own ticket. I'd like that we gather prons and cons for it ( + we could try to start writing ADR as we had discussed before)