The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Moderated By: justafish
Hello! Welcome to to our weekly JavaScript initiative meeting. It happens every Monday right here in Slack! :arrow_left::v::arrow_right:
- This meeting is chat-only. There is no video or audio component.
- We leave about 5 minutes between topics, sometimes more, so that people who are multitasking - The meeting is threaded, so please keep an eye on thread notifications (this may not pop an alert depending on your settings.)
- Please DM me if you would like any items added to today’s agenda!
1️⃣ Please introduce yourself if you’re attending today’s meeting :wave:
| justafish | Sally in :gb: |
| prestonso | Preston in :flag-be: but from :flag-us: |
| dawehner | Sally in :office: |
| gabesullice | Hello all! :flag-us: in :flag-fr: |
| eojthebrave | Joe :wave: stopping by to see what this is all about |
| markie | is lurking |
| drpal | Matt in :flag-us: :eagle: |
| webchick | Angie in :canada: |
| ckrina | Cristina, still landing :slightly_smiling_face: |
| mglaman | Matt, wasn't going to lurk. Am lurking |
| lauriii | Lauri in :flag-th: |
2️⃣ We had a good chat with Wim about what we need from the API-first initiative during the cross-initiative meeting this week. The general consensus seemed to be that this will take.. a while :laughing: @dawehner made a start on the weird endpoints we need here
| justafish | @dawehner do you need anything here other than someone to review it? |
| gabesullice | Is the intention to just do GETs first? |
| dawehner | @gabesullice We do just need GET |
| dawehner | Because POSTing doesn't make sense for permissions |
| gabesullice | PATCH? |
| dawehner | Permissions are defined in code |
| dawehner | Saving which role has which permission already theoretically works on saving roles config entities |
| justafish | @gabesullice this is just for the list of permissions available, so we can’t do anything other than GET them |
| justafish | setting permissions themselves are entity operations so that should be covered when we get config entity support in JSON API |
| gabesullice | ah, interesting |
| gabesullice | so the permissions page (Save) would then fall back to a typical form submit? |
| mglaman | The big problem being exposing plugin data over the API which isn't entity, yeah. |
| gabesullice | gotcha |
| mglaman | Not so much having a functional form.. but tackling the concept? |
| dawehner | @mglaman Form my perspective, yes |
| mglaman | I think that's the big win. Because plugins are a black hole that currently are not handled by an API. And we definitely have a lot of those in Commerce. Permissions are the simplest use case |
| dawehner | The question is: should we expose all the plugin data |
| dawehner | I think it is tricky because not necessarily every plugin type would have permissions assosiated |
| mglaman | Yeah that's hard. Like state_machine so you know an order's workflow - maybe. Because maybe we have a transition endpoint and you need to describe it's workflow? |
| gabesullice | yeah, that's a dangerous road to go down |
| gabesullice | handling access to all that will be very difficult |
| mglaman | If we can provide a way to expose plugins that isn't a tree for all |
| mglaman | Ugh, mobile autocorrect. Free, not :evergreen_tree: |
| dawehner | So we are okay having a custom rest plugin for that? |
| mglaman | I believe so. Something that helps make it easy but not loose like a goose |
| mglaman | I'm really trying to dig into our API and JS stuff to make commerce slick. This would fall into more full admin API. But still a fritical path |
| justafish | @dawehner sounds good to me :+1: |
| justafish | If someone could test/review Daniel’s patch that would be v helpful! |
| gabesullice | I'll do a review |
This message was deleted.
| dawehner | I think we should discuss what we focus on. Right now we have a) a special form b) config forms. Content forms would be a third bit. I'm not sure focusing on that now would be good |
3️⃣ We want to publish ! Who needs to sign off on this other than myself, @drpal, and @webchick? (Initiative leads)
| justafish | Wim and/or Mateu? |
| dawehner | Probably a framework maintainer |
| justafish | Hi @lauriii :grinning: |
| gabesullice | What's the best way to provide feedback on that doc? |
| dawehner | I guess we want one for frontend and backend? |
| gabesullice | here or comments? |
| justafish | @gabesullice here is good! |
| gabesullice | > Allow routes to be seamlessly passed back and forth between React and Drupal I think is a bit too ambiguous. It's a high-level goal, but I think it has the potential to seem like we're trying to recreate FAPI on the frontend |
| gabesullice | and have them share a common API |
| justafish | @gabesullice so what we mean there is we want to fall back to Seven for pages we haven’t built yet |
| justafish | so it will literally switch back to Drupal |
| justafish | so Drupal and the new app will each need to be aware of which one of them should be handling which routes |
| lauriii | I assume we should have feedback from a release manager as well? |
| webchick | Well, this will be run past all core committers once it passes internal team muster |
| dawehner | @lauriii Mh, even we don't provide something releasable yet? |
| gabesullice | Is the idea there that something is taking over routing at the window-level then (forgive me, I have so little history here) rather than components built into a page generated by drupal? |
| webchick | I just figure there’s no point in showing core committers something that the team itself doesn’t have agreement on. :slightly_smiling_face: |
| justafish | @gabesullice yes |
| justafish | just a normal React app |
| justafish | no progressive decoupling/drupalisms :grinning: |
| gabesullice | nice |
| gabesullice | So then core admin would just load a react app by default, with "pass-through" |
| justafish | correct |
| gabesullice | :+1: |
| justafish | @drpal has been looking at this piece (I think - correct me if I’m wrong!) |
| drpal | @justafish I will be looking at that part this week. |
| drpal | So yes. |
| justafish | :partyparrot: |
| justafish | ok so let’s clarify that section of the document |
| gabesullice | Perhaps a rephrasing to: > Allow routes not handled by React to pass through to Drupal's rendering system |
| gabesullice | would have cleared up my initial misunderstanding |
| mglaman | I have a side topic and Q about admin, which is probably best to save for after this - correct? |
| drpal | @gabesullice I like that wording. |
| drpal | @mglaman DM myself or @justafish and we’ll add it to the list. |
4️⃣ Some members of the API First initiative have suggested that instead of pursuing the permissions page, we do something which involves content entities. @gabesullice recommended admin/people
| dawehner | What makes admin/people better suited than admin/people/permissions? |
| mglaman | Wouldn't user management be kind of difficult and force supporting bulk user operation? |
| gabesullice | The current roadmap targets 8.6 and JSON API is targeted for 8.6 as well. My concern is that by targeting permissions/config, we're not working "with the grain" of what API-first has been focused on.
By focusing on /admin/people, we get a page which will have mostly native support in JSON API/REST |
| lauriii | I would guess it is something we are more familiar with since those are the resources we exposed first |
| gabesullice | it's not highly overridden by most modules |
| gabesullice | and it has the potential to show off neat features |
| gabesullice | like live filtering by name/email |
| gabesullice | or infinite scroll when bulk blocking spam users |
| justafish | @ckrina would be good to get your thoughts here too |
| ckrina | I like the idea of showcasing this features |
| dawehner | When we discussed it last time we want with the permission page, because it has a horrible UX right now, so fixing that was an easy win. |
| ckrina | And actually redesigning permissions page is totally independent to other design components, but this one would let us reuse elements |
| gabesullice | @mglaman > Wouldn't user management be kind of difficult and force supporting bulk user operation? can you elaborate on this concern? |
| justafish | The permissions page is a much smaller set of features to implement from a front-end perspective imo |
| gabesullice | Are you talking about the VBO usecase? |
| ckrina | also, permissions is independent and is an easy win... but not an easy design :slightly_smiling_face: And I'm afraid it might slow the development part |
| dawehner | @justafish Is that a +1 or a -1 for the permission page? |
| justafish | @dawehner I’m still thinking about it, I’m just installing a fresh D8 so I can look :wink: |
| mglaman | @gabesullice my concern is bloat of scope. Requires a lot of additional work |
| prestonso | From a purely user's perspective, I would be -1 for the permissions page, solely because that's one of those one-and-done pages that Drupal users don't touch often |
| prestonso | In terms of impressiveness/optics/profit |
| justafish | haha that was one of the reasons we chose it - it’s very limited in scope |
| prestonso | @justafish right there with you — I agree starting small is the right move |
| gabesullice | @mglaman I'm assuming extra work in the react UI side of things? not the backend? |
| ckrina | So, what is exactly the goal? Limited scope? |
| dawehner | For me working on permissions will allow us to learn which infrastructure bits we need for any page |
| dawehner | When we work on admin/people we don't need those anymore and can focus on the API side of things instead of also focusing on the react infrastructure |
| gabesullice | To be clear, I think these are both excellent proposals.
My reading is that the purpose of "Reactifying" a page isn't really known right now. |
| gabesullice | I.e. is it about glitz and glam |
| gabesullice | or is it about discovering missing features |
| gabesullice | or is it about the smallest MVP |
| dawehner | Maybe it is more about time spent and see how much can be implemented (I'd love to see a permission live filter) |
| justafish | for me, the smallest MVP because we have lots of hard problems to solve before we can get into the bit of just writing React components/pages |
| webchick | I think for now, it’s the “simplest thing that can possibly work” to discover holes in the implementation. |
| webchick | And then as a longer-term goal, a “glitz and glam” on a particularly painful admin experience, such as Field UI |
| justafish | +1 |
| ckrina | Maybe adding more options is not the best idea, but what about Appearance page? |
| dawehner | @ckrina in parallel to the permissions page or as alternative? |
| justafish | What’s the objection _against_ permissions page here? That JSON API isn’t supporting config entities properly yet? |
| webchick | But “glitz and glam” is blocked on snazzy designs, and I’d really love to have something to show for this initiative in 8.6, even if it’s on Github and not core for now |
| webchick | @justafish I think yeah, it’s that API-First and JS teams are working at cross-purposes |
| ckrina | @dawehner As an alternative to an isolated option |
| webchick | API-First is working their asses off to get content entities in good shape w/ JSON API. And JS is off the beaten path on some “not an actual API” thing (permissions) that talks to config entities (not a focus of API-First) |
| gabesullice | It's not that JSON API doesn't support it, it's that the internal APIs that JSON API builds upon ar not there for non-content entities |
| justafish | sorry, I’m totally confused by that @gabesullice :laughing: |
| justafish | so it does support it? |
| webchick | So would be a matter of how to bring alignment there, be it having API-First instead doubling down on config entities, or JS instead doubling down on content entities |
| gabesullice | My hope is that, as @webchick is saying, we could find a place that would be both easy for JS to do and easy for API-first to support |
| dawehner | In case someone actually wants to fix that instead of talking about it and complaining: needs help |
| dawehner | @ckrina Do we have UX problems on that page right now JS is helpful for? |
| ckrina | @dawehner good point. No, I don't think JS would make a huge difference there |
| gabesullice | @justafish the gist is that it's not safe to expose config entities over an API right now. Most of their validation is baked into the Form API, which we can't hook in to |
| justafish | @dawehner no one is complaining, we’re just trying to figure out what’s possible with our given resources/directions :slightly_smiling_face: |
| justafish | @gabesullice gotcha |
| webchick | Right, I’m not reading “complaining” out of this, merely how to extract the most awesomeness given constraints. :slightly_smiling_face: |
| dawehner | @justafish yeah I just wish there would be less talking about it since 1.5 years. The time could have been invested better |
| dawehner | Sorry for my :sass: y-ness |
| gabesullice | so `/admin/people` was my best thought for finding overlap. Working with content entities would really show off what API-first can do well AND show off what React can do well. Other pages might do that better, or perhaps that's better for a later cycle |
| webchick | I do agree with @dawehner though that one way or another, we need to tackle the config entity problem, and every time we kick the can down the road we only elongate the timeframe of doing something really impressive with headless. |
| webchick | My worry with admin/people (and also admin/content) is that those are Views. |
| justafish | I think it’s better for a later cycle |
| webchick | And we made a big deal about how they’re Views and thus customizable by the site builder |
| webchick | And once we React-ify it, I’m guessing UI configurability goes away, yes? |
| gabesullice | Yes |
| mglaman | @webchick that's my concern. Replace a view... Need to handle more expectations |
| dawehner | @webchick Thank you for bringing up this point. I didn't dare to |
| justafish | our goal for this phase isn’t to show off what API-first can do, our goal is architect some kind of peace treaty between Drupal and a React application :stuck_out_tongue: |
| gabesullice | Unfortunately, all content listings will be Views by definition |
| dawehner | And let's be honest, this was a reason why we pushed views into core in the first place. |
| webchick | Correct. |
| webchick | And I’m guessing we can eventually find a way to represent Views in React, but not sure that’s a good “step 1” project. |
| dawehner | For custom content modelling adapting these UIs is helpful |
| justafish | Ok so… |
| dawehner | @webchick yeah its another potential auto-generation level complexity |
| webchick | Yep. |
| justafish | On this message, please add a thumbs up for sticking with permissions as per our roadmap, or a thumbs down if you think we should do something else |
| justafish | (just to gauge where we’re all at atm :slightly_smiling_face: ) |
| webchick | me is not voting because there’s no “sideways thumb” emoji :smile: I don’t have a preference, I’m just trying to ensure all concerns are represented |
| justafish | haha |
| justafish | @webchick gotta make a decision! :wink: |
| dawehner | @webchick You could use "shrug" |
| lauriii | thumbdown only because of I’m concerned how long implementing that will take from us, and whether we should be able to ship something visible earlier |
| webchick | And if we stick with permissions page (which looks like we are, and that’s fine), how do we address @ckrina’s concerns that this is not a “low hanging fruit” design-wise? |
| justafish | @lauriii us === api-first initiative? |
| lauriii | us, api-first + JS modernization |
| justafish | I think the nice (?) think about the permissions page is that it’s so simple we’re not going to burn a bunch of energy re-creating that part in React |
| justafish | so for me it’s ok if the first iteration of this isn’t much different |
| dawehner | It is certainly not wasted effort |
| lauriii | I agree that the effort put into that is valuable |
| dawehner | So let's get action items out |
| dawehner | a) Make a product level issue: Replacing admin/people with a JS page. Are we okay with skipping views? |
| lauriii | I’m just wondering if the JS team should be focusing on another UI to be Reactified until the required API’s for the permissions page have been sorted out |
| ckrina | That sounds like a good backup plan @justafish |
| justafish | @lauriii we can build with fake data for now |
| justafish | The focus here is seeing if we can get the inter-operability with Drupal and a React app |
| dawehner | yeah the API side of things is not the main "problem" of this page, which is nice in some way. |
| justafish | it’s a simple page that uses read and write |
| lauriii | @justafish fair enough, that allows us to do development, but not necessarily to release something |
| justafish | @lauriii we’re not planning on releasing anything into core |
| justafish | these are just some goal dates |
| justafish | that should be clearer on the document |
| lauriii | good point, but I think release could be also targeted for the developer community as it is in this case |
| gabesullice | I did not realize that |
| justafish | the things we commit into core will be all the API work etc |
| justafish | but not planning on putting the theme in as an experimental module |
| justafish | well maybe something for 8.7, depending on how it’s going :laughing: |
| justafish | but we need to figure out how to package it all up etc |
| justafish | since Drupal doesn’t have a build step |
| justafish | so, lots of problems to solve before we get to that part |
| dawehner | It'd be nice to pull it in as composer/npm dependency for testing things out though |
| justafish | yeah, for sure |
| justafish | but I think that’ll be a case of “wanna try out to the new stuff? composer require vfancy” |
| justafish | or something |
| justafish | _waves arms around vaguely _ |
| lauriii | I think it is fair to assume developers to do something like that |
| lauriii | is there particular reason not to use the extensions we have (themes and modules) for this purpose? |
| dawehner | I could easily imagine we need some work on the PHP side of things, so we night need a theme and a module actually. |
| justafish | maybe a module, not sure sure we need a theme |
| justafish | @lauriii it’s a standalone React app, it just doesn’t need it |
| justafish | but maybe we we package everything up it’ll have to do something like that? |
| justafish | my biggest goal is to have something very familiar to JS/React developers |
| dawehner | For me though this is an implementation detail, which we might not be able to plan for now. |
| justafish | agreed |
| lauriii | yeah, we have multiple options to choose from when it’s time for that |
| justafish | ok going to update the doc now with feedback from here, gimme a few ticks |
| justafish | I’ll add a notes column because I can’t User Story :wink: |
| justafish | ok, did I miss anything? Does that clarify things better? |
| ckrina | ok, so the Permissions page will be the first design needed, not the field UI right? |
| justafish | yeah that’d be good |
| justafish | but we can also go ahead without a new design, so don’t feel like it would block us :slightly_smiling_face: |
| ckrina | great, this is important too :slightly_smiling_face: |
| ckrina | Maybe something like wireframes that can be implemented with other designs would be useful? |
| justafish | @ckrina yeah that’d work! |
5️⃣ We have 5 minutes or so left, any other items?
| dawehner | Are we confident with converting the nightwatch work into a patch on at this current state? |
| justafish | there’s still a couple of open PRs |
| justafish | I’ll address the feedback you left on mine later and get that in |
| justafish | Someone needs to review Alex’s lock PR |
| justafish | but then, yes, I’m happy for it to be a patch :slightly_smiling_face: |
| dawehner | I reviewed the d.o. issue |
| dawehner | I'd like to move modules out of scope for now |
| justafish | has been moved to a d.o issue? |
| justafish | @dawehner I really want us to have module support |
| justafish | it’s a small addition for a big win |
| justafish | plus then we can see how other people who aren’t core developers might use it |
| justafish | i.e. more than 4 people :wink: |
| dawehner | needs updates from the issue |
| justafish | is this the issue? |
| dawehner | @justafish it is |
| justafish | sorry, |
| justafish | jinx |
| justafish | ok so if this is going in as a separate issue then we need that committed first |
| dawehner | Yes we should. This doesn't block anyone from reviewing our main nightwatch issue though, as long we document it properly in the issue summary. |
| justafish | ok so should I remove the install script from the patch or post them together? |
| dawehner | Well, one could create two patches. One for review, one for sending it to the testbot |
| dawehner | Or we wait till the other patch is done. |
| justafish | @dawehner is it close? |
| dawehner | I'd say so |
| dawehner | I just made some review and changed a couple of them |
| justafish | ok, let’s wait and come back to this next meeting if it’s still not done :slightly_smiling_face: |
Comments
Comment #10
justafishComment #11
justafishComment #13
justafish