[MGNLFE-124] Move the personalization service from libraries to demos Created: 27/Sep/21  Updated: 18/Oct/21  Resolved: 11/Oct/21

Status: Closed
Project: Magnolia Frontend Helpers
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1.0

Type: Improvement Priority: Neutral
Reporter: Bartosz Staryga Assignee: Canh Nguyen
Resolution: Done Votes: 0
Labels: VN-Implementation
Remaining Estimate: Not Specified
Time Spent: 1d 1h
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by MGNLFE-122 Update Angular and Vue demo project t... Open
Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: Headless p13n
Sprint: HL & LD 38, HL & LD 39
Story Points: 1

 Description   

Currently in client side we need to add some parameters to call fetching pages:
https://git.magnolia-cms.com/projects/MODULES/repos/frontend-helpers/browse/samples/spa-react-minimal/src/App.js#32
https://git.magnolia-cms.com/projects/MODULES/repos/frontend-helpers/browse/samples/spa-react-minimal/src/App.js#33

It would be bit easier if could on client side to following:
add ALL query search parameters when fetching page from delivery endpoint

If preview iframe URL is: /travel/?mgnlPreview=false&mgnlChannel=desktop
Then URL to fetch pageswould be: some-url?mgnlPreview=false&mgnlChannel=desktop

If preview iframe URL is: /travel/?previewPersona=%2FSara-Byrne&mgnlPreviewAsVisitor=true
Then URL to fetch pages would be: some-url?previewPersona=%2FSara-Byrne&mgnlPreviewAsVisitor=true

Why it's good?

  • it would allow us to get rid of methods on JS libs
  • it would be future proof. Lets say we develop new feature that would do A, then on Magnolia side we would just attach query param to iframe preview URL, and client side would not have to be modified at all, as it would pass correct params already, and then our rest can look for them (think of it you could have already pass as query params selected variants for specific comps and make pages endpoint resolve it on Magnolia side, and you would avoid the variant choosing logic in client side libs)
  • no extra work needed to support other framewroks/scenarios as it is all about passing query params, so on browser we know to use location.search, on e.g. next.js args.locations.search and so on. Developers would know how to pass the needed bit

Looks like for personalization you'd have to start adding `variants=all` to iframe preview URL.



 Comments   
Comment by Christopher Zimmermann [ 27/Sep/21 ]

Do I get it right - that you are suggesting to not add the PersonalizationService to the libraries - and that the impact would be to change this demonstration project to always append full querystring in requests to the delivery endpoint?

Comment by Bartosz Staryga [ 27/Sep/21 ]

Should it be "add ALL query search parameters when fetching delivery endpoint"?
Yeah, that's what I meant

Regarding `variants=all`
Now this param is never added to the preview iframe URL and is explicitly added by PersonalizationService method (https://git.magnolia-cms.com/projects/MODULES/repos/frontend-helpers/browse/packages/template-annotations/src/service/PersonalizationService.js#54), hence the change on Magnolia side would be needed too.

Regarding adding PersonalizationService
They still need to be there, as some methods are used inside libs, to pass correct variant content
What I suggest is that this should not be exposed to devs, as imho it brings extra complexity which can be avoided by doing what you wrote always append full querystring in requests to the delivery endpoint

It's very nice for future if we e.g. decide to modify how things work in p13n, name of params e.g. or we add new feature `topherView` which will make rest endpoint return everything translated in klingon.
Magnolia has full control over how preview URL looks like so it would add `topherView=true`, no extra stuff needed to be added to our editor libs, not extra work needed on template code as we already pass all query params.

Comment by Christopher Zimmermann [ 27/Sep/21 ]

Discussed with canh.nguyen and headless team and we agreed to remove public Personalization methods from library code. (And add them to the demo project as an example of implemenation.)

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