[MGNLFE-13] Rename SPA components Created: 13/Jan/20 Updated: 20/Apr/20 Resolved: 09/Apr/20 |
|
| Status: | Closed |
| Project: | Magnolia Frontend Helpers |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.0.1 |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Christopher Zimmermann | Assignee: | Lam Nguyen Bao |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 0d | ||
| Time Spent: | 3d | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Template: |
|
||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||
| Documentation update required: |
Yes
|
||||||||||||||||
| Date of First Response: | |||||||||||||||||
| Epic Link: | SPA Editor | ||||||||||||||||
| Sprint: | 6.2.1 Ramp-up 21 | ||||||||||||||||
| Story Points: | 5 | ||||||||||||||||
| Description |
|
The components in the frontend libraries include a mix of mgnl and magnolia in their names which is exposed in the browser and Angular developer tools. Customers may not be too keen on exposing the CMS they use in the DOM. Proposal: align & rename components in libraries, using exclusively the "editable" prefix, e.g. In Angular: // component selectors, as visible in browser inspector * mgnl-page → editable-page * mgnl-area → editable-area * mgnl-component → editable-component // TypeScript class names, as visible in Augary development tool * MgnlPageComponent -> EditablePage(Component) * MagnoliaAreaComponent -> EditableArea(Component) * MagnoliaComponent -> EditableComponent -Component suffix may either be omitted (consistency between Magnolia components) or added (Angular conventions https://angular.io/guide/styleguide#style-02-03); React should be aligned accordingly too. Samples need to be updated as well. |
| Comments |
| Comment by Mikaël Geljić [ 15/Jan/20 ] |
|
It's less about advertising than it is about namespacing (with convention for a given framework) and so we can use simple/rememberable names ("managed" prefix defeats that purpose imo); could be cms-page /area/component though, would be a fair compromise between generic/specific and avoid clashing with arbitrary other things (on top of being consistent w/ page comments). |
| Comment by Christopher Zimmermann [ 15/Jan/20 ] |
|
I don't think namespacing is a problem technically: https://stackoverflow.com/questions/50074276/how-to-import-two-component-but-same-name-from-two-libraries I'm hesitant to go with 'cms' because we're shifting to a DXP and the 'cms' term seems to be on the way out. People are mostly talking about 'content as a service', 'content infrastructure' etc. (https://kontent.ai/. ) |
| Comment by Mikaël Geljić [ 16/Jan/20 ] |
|
|
| Comment by Christopher Zimmermann [ 16/Jan/20 ] |
|
Hah, yeah I was going to propose that (no prefix) - but deleted the comment halfway through because: It would be very confusing to have a frontend componet called "Component". It would be hard to talk about. So we at least need a prefix / postfix on that one element. If we are going to prefix one of the components then I think it aids comprehension to prefix all of them. Its clear that they are all from the one library, focussed on making the JS app 'managable'. Also 'Page' and 'Area' are pretty abstract. Also 'Page' component does show up in some UI component libraries, and it can be a different meaning in the context of SPAs so some disambiguation would be relevant in some cases.
|