-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Use generics in generator-angular #27550
Conversation
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.
As I've stated in #27289 (comment).
- It's possible to use modularized types in generators, but it cannot change default BaseApplication type.
- BaseApplication type should contain every property since it will be used by blueprints.
- Generator specific type should not inherit ApplicationType.
Others changes looks ok.
Blueprints does not use angular properties right? Otherwise, shouldn't they be considered as angular blueprint extension? I'm not sure of what you're mentioning in the previous sentence: may you please either comment the code or provide a PR + comments on changes on this one to make it really crystal clear? I definitely thought that leaf application-generator (like angular) could extends application-base with their own Application Type (extending BaseApplication), Entity and even fields extensions.
To me base app just contains common application's fields
Blueprint should be able to extend any generator, not only base. Also, there's no real point to get frontend-framework-specific properties (like angularlocale). Blueprint should also be able to create their own flavor of BlueprintApplicationType, extending as much ApplicationType Object they want.
That was the cornerstone of that PR: to extends BaseApplicationType and BaseEntity why shouldn't? |
Please explain the rationale of refusal or accept this PR: I'm eager to contribute to the codebase by cleaning this up. Huge improvement like the whitelisting of C vs R vs U vs D at every level, any layer filtering or pivot object between MS need a fully object-oriented, strongly typed and modular approach. This first PR is here to align a clear practice and standard concepts before applying it on every generators to then being able to scale the project by unlocking a safe, straightforward and standard guideline for contribution. PR can't be stuck without any comment or remark, I'm available for discussion on any channel, even meet for voice-over. There are business needs behind the evolution of the platform, and I'm one of the representative of a company that bet on this stack to reach expectations. Ignoring contributors is synonym of either putting users onto pressure or even loosing them, which is the opposite of a sane OSS initiative which should be seeking for both usage and community. I definitely would prefer to contribute to the framework quality to be confident on what I promise to my 200 devs using it on a daily basis which requires these new features (from which modularity and best of breed object oriented approach is a prereq) rather than doing powerpoints to commit the business and managing escalations on a daily basis since this small first step paving the way of the planned improvement is challenged, accepted, scaled and deployed Best regards |
OK, much more clear. |
98ec46b
to
14b0257
Compare
|
0e6a7f4
to
0bccf4d
Compare
There are lots o new changes since last review.
|
No no, I just touched 2 lines since last review (the 'deprecated-types.ts' file, 'ensure retrocompatibility' commits), I was forced to rebase, and as older commit went in between (and conflict) was forced to merge conflicts |
|
Sure it's not, but the wrapping object is. Let me change the filename |
24845cb
to
68358ab
Compare
Hi @mshima, Seems that there's no remaining review point to tackle on this one, is it? Best regards, |
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.
Why an additional types files?
I don’t get types-partial.
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.
That 'partial' type is made to ensure compatibility with the current implementation (avoid breaking change).
in the end, the goal is to have something like this
So that we'll be able to spot which 'Generator' need which 'Type' leading to:
- Better identifying the impacts of the modification of a type or core logic.
- May be release leaf generators independently (or at least communicate the breaking changes on modules for blueprints, i.e. @generator-jhipster/angular, ...): maybe someone just want to consume 'or a leaf element' .
- Spot the generators to modify when we want to introduce a new feature.
- Respect LISKOV (the LSK)
- Avoid this 100 attributes 'applicationtype' (same for platform, entity and field) with some of them not being useful at all in the generation chain for some topologies (i.e. the 'angularLocale' for react generator...)
56fa386
to
19f38c2
Compare
Review comment fixed (now), sorry for the one I forgot, messed with some other branch locally |
Co-authored-by: Marcelo Shima <[email protected]>
We have PartialAngularEntity and AngularEntity now. That's bad. |
The Partial is here to be decomissionned for next version: while retrocompatiblity won't be needed anymore. |
Hi @mshima , Is it OK now? |
I've no clue to improve the current PR. Made my best to keep the retrocompat + improving the codebase. Thanks |
In my opinion types are in 'good' shape now. You should open a new issue explaining the types modularization reimplementation and assign yourself. |
Improvement of #27289 (this one can be reviewed before because it's much simpler)
Would definitely be happy to get a review in order to scale it to all the generators if the committers do feel like me thinking that it makes the code more clean ;-)
Please make sure the below checklist is followed for Pull Requests.
When you are still working on the PR, consider converting it to Draft (below reviewers) and adding
skip-ci
label, you can still see CI build result at your branch.