0️⃣ Who is here today? Comment in the thread to introduce yourself. We’ll keep the meeting open for 24 hours for all time zones.

kimb0 Kim :wave::skin-tone-2:
Griffyn Heels Griff, Aus :wave:
larowlan lee, QLD AU
thejimbirch Jim, Cape Cod
DanielVeza Daniel :flag-nz: :flag-au:
John Pitcairn John, New Zealand.
smustgrave Stephen just being a fly on the wall
Dallas Ramsden (dreambubbler) Dallas, New Zealand - here witnessing magic to tell others intelligently about its value
acbramley :wave:
brianperry Brian, Chicago
cellardoor Chris, Seattle USofA
finnsky Ivan. Serbia
lauriii :wave:
penyaskito :wave::skin-tone-4:
wimleers (he/him) :wave: from Ghent, Belgium :european_castle:  Catching up here after I respond to the flurry of activity over at #3440578: [PP-2] JSON-based data storage proposal for component-based page building :nerd_face:
e0ipso :wave::skin-tone-4:
ctrladel :blob_wave:
guptahemant Hi everyone, Hemant from india

Participants:

larowlan, thejimbirch, DanielVeza, guptahemant, cellardoor, lauriii, Wim Leers, acbramley, catch, gabesullice, joachim, ctrladel, Griffyn Heels, Dallas Ramsden (dreambubbler), Kristen Pol, mattgyver, brianperry, Jesse, smustgrave, penyaskito, kevinquillen

Comments

griffynh created an issue. See original summary.

griffynh’s picture

griffynh commented
Issue summary: View changes
griffynh’s picture

griffynh commented
Issue summary: View changes
griffynh’s picture

griffynh commented
Issue summary: View changes
griffynh’s picture

griffynh commented

1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread, and we’ll open threads for them as appropriate.

larowlan Tokens and typed data
thejimbirch Any discussions/efforts into bubbling up data from components for use in schema.org vocabularies or meta tags?  That is something we've never easily been able to do with Panels, LB, or Paragraphs. (edited)
DanielVeza Prettier configuration (#3452828: Update eslint prettier configuration)
larowlan cypress vs vitest for tests
guptahemant As a developer what’s the best way to get involved, what is the overall startergy for the implementation of the experience builder?
griffynh’s picture

griffynh commented

2️⃣ Subtopic 1: Theme builder (edited) 

cellardoor To catch me up here: Is the idea behind the theme builder to have a way through the UI to control what was traditionally in the theming layer?
lauriii On a high level, that's the idea. I posted a write up on the vision for that in #3450621: [later phase] Theme Builder vision
griffynh’s picture

griffynh commented

3️⃣ Subtopic 2: Page builder frontend

cellardoor I guess this is related to my other question around the UI/UX for the page builder. Understanding what people's ideas are on what's in-scope and what's out of scope for page builder would help narrow it down.
cellardoor I've been incredibly impressed at Bricks page builder: https://bricksbuilder.io and how they have such fine control over the entire layout but have thought through the modularity and extensibility of the page builder more than any others I've run into. I've built several small production sites with it and haven't had to write a single line of theming code, which I would think would be an ideal goal for starshot/experience builder.
cellardoor The idea that you can build a whole site with no code, yet not limit what you can do with the builder if you do want to extend it with code blends the power users that we typically cater to for Drupal while allowing the platform to be more accessible to non-developers
wimleers (he/him) @cellardoor @lauriii did evaluate that. He showed us pieces of it. @lauriii can expand :slightly_smiling_face:
griffynh’s picture

griffynh commented

4️⃣ Subtopic 3: Data model/persistence layer

larowlan There has been a lot of activity on this front in the repo
larowlan as well as a lot of comms in #3440578: [PP-2] JSON-based data storage proposal for component-based page building
larowlan I've been chatting with catch and wim about a few things, but its been tricky to have multiple DMs going, so bringing the comms here
larowlan The current state of those comms from my POV:config entity that represents a componentfor each component the site builder can say for each prop one of the following;Option 1 Fixed value (set in config entity)Option 2 Dynamic value taken from base entity - mapped in config entity, site builder picks widget and formatterOption 3 Arbitrary value use this widget, use this formatter, mapped in config entity *may not be needed, read onIn the edit form for content editors the first option above doesnt showOption two (Dynamic) shows but stores in content entity field, with reference in treeOption three stores arbitrary typed data in the tree *may not be needed, read onWith this model, the config entity had a config dependency on any fields it maps to, as well as widget/formatters (module dependencies) so we can manage dependencies on fields etcIt also has an entity-type and bundle implied by way of the fields it uses. This limits available things in the component list, can't use a component that relies on fields that aren't thereThe config entity can also record 'slots I work in' ala layout builder restrictionsI think that also lets you change the mappings later - want the 'hero title' component to use a different field for the image, change it in the content entity, no need to update the treeI discussed this with Catch and he asked do we even need to distinguish between Option 2 and Option 3 - can we not just dynamically add fields to the content entity and remove option 3 - always storing values in fields on the entity. This is what @gabesullice has been proposing in [#3440578]Catch and I brainstormed that a bit - the example I used was thislet's say you have a tab's component, in the second tab, it uses a two-col layout, the left col has a slider in it, in that you have cards, each card has an imageIn that scenario I guess you could pick out common shapes and make fields on the fly for them - eg, in that scenario it might spot the following:image field on the card => media reftitle field on the card, title field on the tabs, title field on columns => string fieldbody field on column two, teaser field on card => text fieldSo that would be 3 fields and then the props could say 'tab 2 title is delta 3 in the title field', 'card image 3 is delta 3 in the media field'This would mean you need to limit components per bundle - but that is something we'd probably want anyway - LB restrictions is already per bundle. So if you said 'this component can be used on articles' we would analyse the mapping and go off and make sure the required fields exists.My concern is I don't think we should be asking content-editors to 'pick the field you want to populate this prop from'. I think site-builders should make that decision ahead of time. If there's multiple options, they should make multiple components (config entities). I think asking content-editors to think about data-structures and fields is like asking them to think about formatters like LB field blocks, which is something we avoid on client projects.I think content editors should just be filling in fields using widgets the site-builder decided make sense for a prop in an SDC, no different to what they do now for LB/Content  forms/Paragraphs
acbramley I think site-builders should make that decision ahead of timeBig +1 on this. This is a major issue people have with the flood of LB blocks editors get (edited)
catch As I understand it, option #3 is closest to what's currently in the repository and means handling things like as field type usage in #3444424: [META] Configuration management: define needed config entity types is also relevant here.
gabesullice Something I want to clarify about my thinking on this.In my head, components are fields and maybe inline blocks. Sections are the containers they live in.Simplest component == solitary fieldMedium complexity component== composed fieldComplex component == inline block instance (or slotted section, see following comment)That means component markup is encoded in block and field templates.I'd expect "section types" to be YAML defined config plugins. Site builders would create instances of them per-bundle and choose which field and block types are permitted within them.That means a FED could define a slider carousel that generically loops through its child elements, irrespective of what those children actually are.A site builder would define an instance of that section type as being a "Video slider" by building a "Video slide" composed field comprising a media, text, and link field on the Landing page content type and then restricting the section type instance to only that Video slide field.On a different content type, the site builder could reuse the Video slide field but label it CTA video and then define a "CTA video" section restricted to that field.That means the markup and styles for the video slide would be shared at the field template level so the all "video backgrounds with some text and a button" would be visually consistent.The slider markup and JS would be shared too because another instance of it could be a slider gallery restricted to a composed image and caption field.As you can see, almost all the node data would live in field tables.The only use for inline blocks would be to support a component that needs 1 image and 3 links for example.What the layout field would be encoding is the section items, their hierarchy, and the field items or inline blocks they hold. (edited)
lauriii My concern is I don't think we should be asking content-editors to 'pick the field you want to populate this prop from'. I think site-builders should make that decision ahead of time. If there's multiple options, they should make multiple components (config entities). I think asking content-editors to think about data-structures and fields is like asking them to think about formatters like LB field blocks, which is something we avoid on client projects.I think content editors should just be filling in fields using widgets the site-builder decided make sense for a prop in an SDC, no different to what they do now for LB/Content  forms/ParagraphsWe should try to write down the use cases and the user journey on a high level so that we can work with UX researchers to validate the assumptions we're making. I'd be happy to help if someone starts a doc on this.
gabesullice We could even get rid of inline blocks by having the idea of "slots" in the section types that could have different field restrictions. So that you could make a section type with 3 slots that allow a) an image field items, b) link field items, or c) child sections. (edited)
wimleers (he/him) (Currently responding at #3440578: [PP-2] JSON-based data storage proposal for component-based page building, will do that first, then continue here.)
gabesullice What the layout field would be encoding is the section items, their hierarchy, and the field items or inline blocks they hold. (edited)As @joachim mentioned in the thread, we don't necessarily need JSON to encode the entire tree. Every section could be a row in the section layout field table. But I think we'd probably want to use the JSON datatype to store the the contents of an individual section (e.g. pointers to field items and child sections) and potentially a little bit of metadata. (edited)
joachim I think we should avoid inline blocks and nesting entities in general.
joachim And layout field - that’s just another field type which controls the presentation of its sibling and child fields in the tree.
gabesullice @joachim, responded to you on the issue. Something really elegant seems to be emerging from your suggestion :partywizard:. Sections become field items which means they could be rendered by a field item widget formatter. (edited)
ctrladel @gabesullice haven't read the new posts but in general sections and blocks being different things should go away. A two column section is just another component that has two slots. I threw together this which explores different ways to model the same component #3446083: Document supported component modeling approaches to help discussions during Drupalcon
guptahemant I think the data storage model we choose should also support for few important use cases,easier data updates via code APIs (minimise actual data migration due to layout changes),translations for multilingual sites Revisions support(edited)
guptahemant Reading through this to better understand JSON field usage idea #3440578: [PP-2] JSON-based data storage proposal for component-based page building (edited)
larowlan We should try to write down the use cases and the user journey on a high level so that we can work with UX researchers to validate the assumptions we're making. I'd be happy to help if someone starts a doc on this.@lauriii where's the best place for this?
lauriii @larowlan we could collaborate on this in a Google Doc first
larowlan thx
griffynh’s picture

griffynh commented

5️⃣ I’m not sure where to start, but want to contribute to Experience Builder.

Griffyn Heels From last meeting: https://drupal.slack.com/archives/C072JMEPUS1/p1716469272981229?thread_t... (he/him) - Is this still accurate?
Griffyn Heels Do we want threads for each of those items?
Dallas Ramsden (dreambubbler) Prepping for a social media / video promotion in a week or so to get more enrollments to June 18 - 14:00 - 15:00 GMT:star:️ Experience Builder Update + Next Steps.I am eager to understand your perspective on what's essential to include. My goal is to make your work be perceived as incredible to those unconvinced. LMK!
acbramley this still holds true at the moment for me, still feels too early to jump in (I also have no time :sad-panda:)
wimleers (he/him) There’s one important evolution since the last meeting, we now have two meta issues for coordination:[META] Early phase back-end work coordination[META] Early phase front-end work coordination… and both have their issues visualized (although not every bullet has an issue yet — only so many hours in a day … until we some day have a project manager that does this): https://contribkanban.com/board/experience_builder(thanks to @mglaman, soon that will show the issues for both of those metas)
wimleers (he/him) Et voila: https://drupal.slack.com/archives/C072JMEPUS1/p1717678224316429
Kristen Pol (she/her) Thanks @mglaman for the boards :smiling_face_with_3_hearts:
griffynh’s picture

griffynh commented

6️⃣ Wins - what wins have you had since the last meeting? Share your successes!

griffynh’s picture

griffynh commented

7️⃣ @larowlan “Tokens and typed data”

larowlan Is there anything we can use/learn from in #2002254: Typed Data tokens: allow addressing, labeling and evaluating a specific value in the (content entity) Typed Data hierarchy — empowering ECA and Canvas. I realise we have a prop expression concept but I wonder if there are existing things we could build on top of our leverage
larowlan Hat tip to c_atch for these
wimleers (he/him) TIL those issues exist, of course @fago created them :joy:
wimleers (he/him) Only 23 followers (now 24) for a >11 year old issue. That’s why most of us didn’t know about it.
wimleers (he/him) Observations:There is very little discussion and code in those issues. I doubt it’ll help us much?Drupal’s tokens only support scalar values, actually only even strings. SDC props may be shaped like ints, bools, heck, even “objects” (a set of key-value pairs). So rebuilding the token system on top of Typed Data alone would not be enough, we’d also need to drastically expand what it can do to meet XB’s needs.This is perhaps the most-developed part of XB currently :sweat_smile: code: https://git.drupalcode.org/project/experience_builder/-/tree/0.x/src/Pro... test: https://git.drupalcode.org/project/experience_builder/-/blob/0.x/tests/s...
wimleers (he/him) @gabesullice :point_up: Thoughts?
larowlan the scalar vs object/array seems like a limiting factor
griffynh’s picture

griffynh commented

8️⃣ @cellardoor “Are there any discussions happening currently around the UX/interface of XB? It seems like a lot of great efforts are going on in the data layer and back end mechanics already but I’m not sure I’ve seen the UX / Interface discussions.”

lauriii There's definitely UX work happening around this. This has been largely owned by Acquia UX until now. There are folks in the community who are interested in helping and I'm trying to find ways for them to collaborate on this with folks who are interested.
Kristen Pol (she/her) Seems relevant https://drupal.slack.com/archives/C06GX5T33/p1717660509500689
cellardoor @Kristen Pol (she/her) @mattgyver do you know what builder that is?
mattgyver It is GhostCMS
cellardoor Looks clean and easy! Gutenberg-esque in how it creates the new blocks.
mattgyver GhostCMS provides a great experience to publishers since day 1
cellardoor I think that's critical for XB to ensure that while we'll build a very powerful builder it's also got layers that allow us to provide a simple interface for people who aren't wanting to dive into all the various ways to tweak the layout
cellardoor for that know what flexbox is and how to manipulate it, we should give that ability, but for those that want to just drop a few blocks on the page from their component library, they should be able to do so without friction
griffynh’s picture

griffynh commented

9️⃣ @thejimbirch “Any discussions/efforts into bubbling up data from components for use in schema.org vocabularies or meta tags?  That is something we’ve never easily been able with Panels, LB, or Paragraphs.”

larowlan see the discussion in https://drupal.slack.com/archives/C072JMEPUS1/p1717630350222699 which I think might make that doable if the prop values are just in fields :thinkspin:
wimleers (he/him) The question is not clear to me. Is it referring to:components (i.e. the combinations of an SDC’s props maps onto/is equivalent with a schema.org Type?)component props (same, but schema.org DataType?)fields providing the data for components (so a mix of the above?)
wimleers (he/him) Drupal entities/fields use TypedData to define schemaSDCs use JSON schema to define schemaXB currently maps between those two. That’s how it figures out what field(prop)s can be used for which SDC props.
wimleers (he/him) This sounds like it’s asking for a third schema definition. That’s not impossible. But it’s also premature currently IMHO.
thejimbirch @wimleers (he/him) Meta tags and Schema.org vocabularies have traditionally been set using the metatag and schema_metatag modules in Drupal.  These are easily set using tokens when the fields are directly related to the node/entity. (edited)
thejimbirch However, when you step into the realm of randomly placing components using the current methods, it is quite difficult to get that content to the node/entity systematically.
thejimbirch An example would be an image placed on the page using XB, but it is needed for the node's Article Schema.
thejimbirch If a component were a self contained schema.org type, like FAQ, the component could have the markup or JSON-LD needed. (edited)
thejimbirch The existing problem we have is getting the structured data markup to the parent level from components.
thejimbirch Some user story ideas:As a content editor, I need the words I type in components to summarized in the page's meta description tag.As a content editor, I need the images, and the image meta data I place in components in the page's open graph image url, image type, image height, image width, and image alt text meta tags (note: alt comes from the image, the rest come from the image style).As a content editor, I need the content from a FAQ component to have valid FAQpage Schema markup or JSON-LD.As a content editor, I need the images I place in components on an Event node to appear in the page's Event JSON-LD.
ctrladel @wimleers (he/him) sounds like another crazy config mapping exercise for you :smile:We're doing jsonchema -> fields and now Jim is proposing authored components on the entity(jsonschema) -> metadata/schema.org but with some form of automations/smarts to auto include content from components to certain schema.org structures(?)Seems like it could use/extend/follow the lead of the mapping work already being done. I agree it doesn't sound critical to initial XB but is a real pain point with component based pages that need significant seo optimization.
thejimbirch but with some form of automations/smarts to auto include content from components to certain schema.org structures(?)I think the "smarts" could be configured by the site builder/recipe if the data was available.authored components on the entity(jsonschema) -> [tokens or similar] -> meta tag/schema.org configuration (edited)
griffynh’s picture

griffynh commented

1️⃣0️⃣ @DanielVeza “Prettier configuration (#3452828: Update eslint prettier configuration)”

DanielVeza This should be a pretty quick one, it's mostly covered in the ticket. The main thing I thought it would be good to get some thoughts on is how far we go with configuring prettier at this stage. I see two optionsBasic setup described in the ticketPros: Faster to implement and fix existing issues, won't get in the way as muchCons: We'll need to move to cores version at some point and do another round of fixesCores setup:Pros: Future us will appreciate that we did this when we move this into core :sweat_smile: Cons: Will take longer to implement and fix existing issues, and is more likely to get in the way during active dev(edited)
DanielVeza I'm happy to do the actual work on setting up prettier and fixing the existing issues - Just interested to get thoughts before I do it
larowlan I've setup ci for linting here https://git.drupalcode.org/project/experience_builder/-/merge_requests/2...
larowlan another pro for custom setup, we can add stricter rules for things that core has no opinion on - eg react hooks rules, testing library rules, redux rules
brianperry Would love to see this someday influence Drupal project standards for React/TypeScript (or perhaps be a new set of standards). For the API client we made a few tweaks on top of the Drupal standards to include TS. Didn't have to wade into any React specific opinions though.
wimleers (he/him) @Jesse :point_up: Can you chime in here so that @DanielVeza can run with this? :smile:
Jesse +1 from me to a custom setup - especially in the short term. I think, as @larowlan says, we likely need/want stronger opinions on things that are specific to this React app.
larowlan https://git.drupalcode.org/project/experience_builder/-/merge_requests/2... is showing a few warnings in HEAD but its a good novice issue to get involved
griffynh’s picture

griffynh commented

1️⃣1️⃣ @larowlan “cypress vs vitest for tests”

larowlan #3452584: [policy no patch] Set expectations around testing for Frontend
larowlan My 2c - we should use Cypress for E2E if that's folks' preference but component/unit/reducer tests should make use of Vitest/testing-library as those are industry standards for React
DanielVeza Big +1 from me to move towards Vitest/testing-library over cypress
smustgrave Never used Vitest(googling now) but I do enjoy cypress.
larowlan https://git.drupalcode.org/project/experience_builder/-/merge_requests/3... sample vitest
larowlan its just jest but with vite
larowlan https://git.drupalcode.org/project/experience_builder/-/jobs/1789333 2secs :sunglasses:
acbramley I question the use of cypress, do we really want to add yet another testing framework to core?
smustgrave Apologize if the conversation has been had but could either option be a replacement for night watch?  (edited)
larowlan cypress is a nigthwatch replacement yes
larowlan vitest/jest are lower level like a unit/kernel test but for js
brianperry I agree that both probably make sense - Vitest for unit test like things, Cypress for E2E.
brianperry I've also had a positive experience using Playwright for E2E testing. Saved a lot of time using their test recorder in VSCode. Cypress might have something similar, not sure.
gabesullice Just curious because I've been evaluating nightwatch vs cypress for something else, what's the problem with nightwatch that cypress resolves?
gabesullice (asking for my own edification only)
larowlan I don't like either of them so don't ask me :upside_down_face:
penyaskito at work we are preferring playwright > cypress, because of better parallel tests support + multiple tabs/sessions support for e2e.I think is more legible too, but that's personal taste.
penyaskito I assume this would only be for new tests, and rewriting existing nightwatch is out of scope. I'm wondering if adding yet another one (cypress or whatever) could be a blocker. But also working on XB should be enjoyable.
gabesullice Thanks @penyaskito
wimleers (he/him) I heard from both @bnjmnm and @Jesse that Cypress is ORDERS OF MAGNITUDE nicer/easier to use, and hence it’s purely a matter of DX.
wimleers (he/him) Looks like @penyaskito has a similar experience :smile:
wimleers (he/him) See #3452584: [policy no patch] Set expectations around testing for Frontend#comment-15627562, where I asked @Jesse and @bnjmnm to document the rationale. Looks like @penyaskito could almost write that rationale too :smile:
Jesse My (not unbiased and not fully informed) opinion is that Cypress is significantly easier to write tests in than other options and I’ve never enjoyed using JEST tests (like I believe Vitest uses).  I hadn’t heard of Vitest until @larowlan brought it up - but then I’d not used Vite until starting this project because I’d only been working on projects started before Vite took off!Cypress offers React component testing and testing-library support so I think there are advantages to using it for both E2E and component tests rather than having two different libraries/APIs.I have seen Playwrite and it certainly has a buzz about it from people who’ve adopted it but I’ve not used it. @bnjmnm and I discussed but ultimately discounted it because it’s not got the same level of adoption as Cypress so we considered it a potentially riskier option.
acbramley I would definitely consider jest/vitest, you really do need a unit testing with complex react stuff and it makes it very easy (and they're extremely fast)
kevinquillen I've used Cypress since v3, writing e2e tests did feel easy and as mentioned an order of magnitude better than previous tools. Jest tests have their place too. Heard of Playwright but haven't checked it out.
penyaskito @Jesse I've no experience with cypress, jumped directly to Playwright. I have the feeling that it's growing a lot, their community is supportive and there are lots of resources. Can't compare with cypress bc I'm not there, but Playwright Discord is quite active and full of resource links in every medium (video tutorials/docs/blogposts/devcalls).
penyaskito Cypress is great, and a good choice if we have more experience with it, but I wouldn't consider playwright risky.
penyaskito if it helps, https://github.com/deviantintegral/drupal-playwright. Includes things like creating a different site per test as simpletest does.and ddev integrationhttps://github.com/deviantintegral/ddev-playwright
brianperry Cypress is great, and a good choice if we have more experience with it, but I wouldn't consider playwright risky.Agreed. My perception is that Playwright is overtaking Cypress in usage. Both are viable options though. And Cypress has been around longer.
kevinquillen I would agree both are viable
larowlan pushed some sample component tests to https://git.drupalcode.org/project/experience_builder/-/merge_requests/38 for comparison
griffynh’s picture

griffynh commented
Issue summary: View changes

griffynh credited acbramley.

griffynh credited brianperry.

griffynh credited catch.

griffynh credited cellardoor.

griffynh credited ctrlADel.

griffynh credited DanielVeza.

griffynh credited gabesullice.

griffynh credited guptahemant.

griffynh credited Jesse.

griffynh credited joachim.

griffynh credited kevinquillen.

griffynh credited Kristen Pol.

griffynh credited larowlan.

griffynh credited lauriii.

griffynh credited mattgyver.

griffynh credited penyaskito.

griffynh credited smustgrave.

griffynh credited thejimbirch.

griffynh credited Wim Leers.

griffynh’s picture

griffynh commented

griffynh credited dreambubbler.

griffynh’s picture

griffynh commented
griffynh’s picture

griffynh commented
Title: Meeting of the Experience Builder Initiative 2024-06-07 » Meeting of the Experience Builder Initiative 2024-06-06
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.