[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: PNG File augary.png    
Issue Links:
dependency
is depended upon by MGNLFE-24 DOC: Components and libraries renamed Closed
relation
is related to MGNLFE-18 Rename libs from @magnolia/react-rend... Closed
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);
it should be considered an implementation detail anyway.

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/. )
(https://www.contentful.com/ 'Web CMSes create digital sprawl — content silos that slow innovation. But a unified content layer enables your team to scale and iterate faster. See ya, CMS.')
I also think frontend devs are going to be somewhat averse to 'cms, cms, cms' in the inspectors. https://www.google.com/search?q=smell+your+cms

Comment by Mikaël Geljić [ 16/Jan/20 ]

 thanks, and yeah, I was hesitant as well; with your additional input, I do see the Smurf Naming Convention in there. Wouldn't it be the same with any other prefix, hence we'd rather go prefix-less and let projects prefix as they wish?

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.

 

Generated at Mon Feb 12 05:43:22 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.