Moderated By: drpal

Hello! Welcome to to our weekly JavaScript initiative meeting. It happens every Monday right here in Slack!

- 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 multitas- 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 or @justafish if you would like any items added to today’s agenda

1️⃣ Please introduce yourself if you’re attending today’s meeting!

drpal Matt!
justafish Hi fam :wave:
mglaman Matt 2, lurking :wave:
jordan.page.white Jordan :wave: multitasking, but listening/reading
moop Mike, lurking as well
lauriii Lauri :parrotdad:
alexpott alexpott
ckrina Cristina, landing :wave:
dawehner Daniel, back in my hometimezone
webchick Angie, Vancouver BC :canada:
mrjmd Matt 3, late and lurking :arrow_left: :v::arrow_right:

2️⃣ @justafish Gives us an update from Drupal Camp Florida on the roadmap document.

drpal Here’s the doc,
alexpott Looks like plenty of config entity work! Looking forward to chipping in
drpal The one thing I would say about this doc, it feels a little ambitious.
drpal There’s a lot of things for 8.6.
alexpott ... and core things can take time ...
drpal @alexpott exactly.
drpal Additionally nothing about the rest of the code-style cleanup?
mglaman Will anyone be at DrupalIron Camp in october? Might be another good date and larger event
drpal @mglaman I guess that depends on Acquia’s budget..
drpal _at least for me_
justafish Hey! Myself, @webchick, @dawehner and @quicksketch had a great planning day on Saturday. We worked out a roadmap for how we’re going to proceed. I think the main points are:
- We’ll try and fallback to Seven for pages that don’t have a new fancy version so we’re not trying to be overly ambitious
- We’re going to work on the permissions page first
- Discussion around how our workflow’s going to be managed if we’re working on GitHub
mglaman I know at CG we're treating it as the Europe replacement
drpal @alexpott @lauriii One thing, though, if a bunch of this stuff can be done outside the core process, it could easily get done along the same time line.
justafish regarding lots of things for 8.6 - because this will be an external app then we’re not explicitly trying to hit 8.6 for all of those parts
justafish yes lots of entity work!
justafish @drpal we were just focusing on the new admin theme initiative here
drpal @justafish You mean, targeted to release at the same time as 8.6?
drpal Not included with 8.6?
justafish Yeah, just enough to get the permissions page working
justafish so components library doesn’t mean a full library of everything ever
drpal The permissions page is not on this list?
alexpott On the last committer call we discussed if there was anyway we could make things easier by having an area where the core process was relaxed. I.e some way of proceeding without trying to do everything at once.
justafish @drpal ah you’re right, it just says e.g. permissions
justafish oh sorry
justafish yeah we aren’t aiming for permissions for 8.6
alexpott So it is really good to hear that we're all on thinking along the same lines - how do we make this manageable and have a high chance of success.
justafish we want to get the “shell” working so we can fallback to Seven for ~8.6
justafish (sorry for the confusion, I flew back this morning and am _p sleepy_ :grinning: )
drpal @justafish I inserted an empty row in the table to get things to line up a bit better.
webchick Yep, that document is still rough, btw, just has my best attempt at capturing the discussion we had all day Saturday
webchick So please feel free to make suggested additions/edits!
drpal I think if we are going to try and target a permissions page for 8.6 then distilling this roadmap down to just that (in another doc or d.o issue) might be helpful.
webchick The goal though is to have “something” to show from this initiative by 8.6's release. It didn’t seem like anyone was targeting getting anything from this initiative actually *committed* to 8.6, though. Which means we’d have the entire runway up through Drupal Europe to get something “demoable”
drpal These are all the things we need to do.
drpal And these are the things about the core process that makes doing them difficult.
drpal etc.
webchick We did talk about doing the permissions page at one point, as well as a redesigned Field UI, but I wasn’t sure that’s where we landed.
webchick (I’m happy to write down whatever, however.)
justafish @drpal that would be more like 8.7
justafish for the permissions page demo
justafish ~8.6 would be the ability to have our app working in parallel with the existing theme so we have a fallback
webchick Where I *thought* we landed was that @justafish doesn’t think it’s a good idea to do a bunch of one-off SPAs here and there for this thing or that thing (dblog, permissions) and would instead prefer to tackle this holistically, with a React app that takes over the entire admin experience, but falls back to Seven in the event we haven’t covered that route yet
dawehner Well, I think we need at least one example to know that the shell and route fallback works
webchick I don’t disagree. I thought for that we were looking at auto form generation tho.
justafish @dawehner yeah, it can be a dummy page that says “Hello world” or something
alexpott Just thinking - nice choice on the permissions page. It does have a terrible UI but it's not super complex like fields and everyone has to use it so it is high impact.
drpal Really wish I’d had the chance to come to DCFL. :disappointed:
justafish @alexpott it also has some custom data that we don’t have an API for, which makes it interesting
drpal Yep. I think the permissions page is a pretty great starting point.
justafish (let’s spin design discussion for that off into a later agenda item we have coming up :slightly_smiling_face: )
webchick Right, we also talked about how to handle this… whether we can do a one-off callback in a “react_admin” module, or whether REST/Serializer needs a generic way to handle “things that are not config/content entities” such as permission names, field type names, modules…
webchick The advantage of not targeting landing anything in core (for 8.6) is I think our github repo can do whatever shitty macguyver hacks it needs to do, that expose the data we need, and core can say “ok, so based on that now we need a BLAH API”
justafish speaking of, we’ll be working here on this ->
webchick @alexpott in terms of entity stuff tho it was definitely brought up repeatedly that lack of CRUD on config entities is going to bite us in the ass trying to do any kind of useful admin-y stuff from React
webchick @drpal And as far as the ongoing clean-up, there was some debate as to whether or not that belongs on the roadmap in a “here’s holistically everything we’re trying to do around javascript” or whether the roadmap should be more “laser focused” on the things that enable the React admin theme
webchick In general, I will say, teams with fewer roadmap items tend to be better off
webchick Prevents stratifying people across too many efforts
webchick And makes it clear which ones are *really* important to nail.
drpal @webchick as soon as it’s not on the roadmap, i’m not going to do it anymore.
drpal :stuck_out_tongue:
webchick vs. which ones can happen whenever
webchick @drpal That was another thing that was talked about. What are the pros/cons of doing that? (Dropping the effort to “nice-ify” 2011 JavaScript that will probably mostly get replaced as part of this initiative.)
drpal The entire point of doing the code-style cleanup in the first place was to get our existing code-base to a place where we could actually lint with the testbot.
dawehner Can we please open up a new thread for the code-style cleanup, please?
webchick Gotcha.
webchick Sure, sorry! I don’t knowhow threading works. ;(
dawehner I think given the assumption we want to have something deliverable I think just focus on config entity support is a bit meh. There are way more people out there able to build a one-off permission page than config entity form generation
webchick True that. :wink:
dawehner Let me rephrase my sentence. I think working on a generic form builder is hard, but needed. Working on a nice UI for permission page is a bit easier, while also needed on the longrun
webchick Yeah, in my mind it’s three things:

1) Some quick-but-useful “proof of concept” so we can show some momentum from this initiative (React-Create-App-based thingy, permissions page)

2) Some “hard, grueling, soul-sucking core work that enables aweosmeness later” which is the config entity stuff, JSON API (and OAUth?) in core, etc.

3) Longer-term “let’s kick Squarespace’s fucking ass” UI awesomeness facilitated by both of the above for 8.7+.
dawehner Let's not forget the fallback. Maybe 1.5 would be a good place for that
webchick Sure!
webchick @drpal did you want to start a big blue “4” for “does cleanup belong in the roadmap or not?” or should I?
drpal @webchick I will do it right now.
webchick Ok cool
dawehner Another reason why I think at least one one-off page isn't that bad is that it helps to identify common ui components
webchick Right, and also finding out some of the “what explodes when you stick Drupal and React together?” stuff
webchick So we seem to have expanded, versus contracted, the roadmap in this meeting. :smile:
webchick And we still don’t have “do the permissions page in react” in there (adding now)
webchick “As a site builder, I would like a permissions page that is responsive and fast-loading.”
webchick Is that why we’re doing this, or..? What’s the goal?
webchick And of the 90 things listed in the roadmap (lol) which ones do we consider “mission critical” to get done (these should be at the top)
dawehner Depending on the definition of mission critical I think everything?
webchick @dawehner So basically, some of this stuff is probably not going to make it into 8.6, just the way things go (holidays, people getting busy with work, etc.)
webchick We should just count on that happening
webchick Given that, we should try and prioritize the items so that if we land only the first, say, 4 things, we still have something useful to show, and it lays groundwork for 8.7 to be awesome and pick up where we left off
dawehner Oh I see, well I think I misread mission critical then
webchick Yeah, I should probably not use slang.

Basically I’m getting at, “What would be the priority of items in terms of things we REALLY MUST land in 8.6, things we REALLY SHOULD TRY TO, etc.

@ckrina has joined the channel

3️⃣ What could Drupal implement from other CMS or content editors to improve its Admin Interface?

drpal
drpal cc. @justafish
dawehner 1️⃣ I think a unified field UI (a bit more like contentful) would be amazing
justafish @ckrina ^
justafish +1 new field UI
webchick A better Field UI for suuuure
justafish hahaha
justafish so Field UI then :wink:
webchick We actually have a pre-existing initiative for that “Data Modeling”… it’s just gone nowhere
drpal I think we talked about a React based UI for FieldUI originally.
drpal But +1.
webchick Yep, I got spooked off by that only because that seems like a release cycle to even come up with the design.
webchick Versus the permissions page is a very known quantity, and it’ms hard to make that *worse* :wink:
justafish yeah, it will be a long process for sure
webchick So this would allow us to kick things off in parallel… announec “hey community, we want to redesign the field UI!” and get the UX/design team/OCTO/whatever going on that,
webchick But still target an “achievable” milestone for 8.6 as well
ckrina it would be great, a huge +1 to that
lauriii better UX for the content adminstration is something we’ve been requested to work on more and more often
justafish so sounds like this is something we should get started on as soon as we can since it’s going to take a while
lauriii even though it might not have the same wow effect for developers, it would be something that would help most likely the widest audience
eaton One of our big strengths — compared to other CMSs — is that we have a variable number of data types and configurable widgets per data type. keystone just requires that every data type ship with a react component for editing :P
eaton There aren’t a lot of examples in other projects that do BOTH
justafish @eatings you’re referring to right?
eaton So, here’s something
eaton Yep
eaton They moved to react for their admin UK a while ago after wrangling with a lot of custom stuff IIRC
eatings Wrong eat*
eaton @justafish I’m an old man who doesn’t really understand New Things that well but it seems like one of the biggest challenges is the fact that fieldAPI totally separates Field data so widgets can be ignorant of what they live on, while a more Reacty approach (unless I’m mistaken) would be to send a JSON representation of the core data and manipulate it on the front end.
justafish @eaton right on
justafish @eaton we were talking about adding a little bit of annotation to config entities as well, e.g. this should be a select and not radio buttons, or please use my crazy custom component
eaton that would make config entities work very much like KeystoneJS
eaton declarative data model with optional hints to specify how editing widgets should work
eaton for more complex stuff like entities, the Dream Future™ would be one where the full entity in JSON lives on the client side, gets edited by widgets, then gets sent back for validation and persistence, rather than having an intermediary Bucket Of Form Fields representation
eaton The downside is that I am not smart enough to think of any way to do that that would degrade gracefully
justafish @eaton you mean work without JS enabled?
eaton Yeah, although I might be thinking back to old and outdated FAPI tricks that no longer apply when I think about things that could make it tricky
eaton Or would PlainOldFAPI be the fallback?
webchick Maybe so.
justafish @eaton I think we have to say if you don’t have JS turned on then we can’t support you
justafish or, use Seven :slightly_smiling_face:
webchick I think fallbacks just have to be functional, not necessarily pretty
eaton So this would be a theme specific kind of thing?
webchick Our non-Views fallback for e.g. admin/content for example is just a table without any bulk operations
eaton fair
webchick And the accessible versions of table drag expose ugly weight drop-downs everywhere.
webchick and so on
eaton The problem (unless I’m confused) is that right now forms are composited together from widgets — and if a content form ONLY uses core we could ensure the whole form would be React-powered, but once third party fields come into play we’d have a mix of old and new style widgets, right?
justafish correct
webchick Not if we piggy-backed off the config schema system, which we discussed doing… and had both React and PHP versions of “autogenerate a form for this”
justafish @webchick I think @eaton means that if a module provides a custom widget
webchick (Or at least that’s my understanding, since config schema is a common API between core + contrib)
webchick Ahhh
justafish they’ll need to provide a new custom widget that’s a React component
webchick Gotcha, yep
justafish if they want to support the new theme
justafish which I think is fine :+1:
webchick I think once it gets into core as default admin theme, they won’t really have a choice. It’ll be an interesting transition though.
eaton So Fields will be divided into React and “Classic” widgets and potentially in D9 or something we might deprecate “classic” widgets
lauriii It would be great to plan that specifically with the release managers
justafish that sounds very reasonable @eaton
eaton And — in theory — you could hand-code a react form from scratch for an entity yourself
eaton ignoring widgets entirely
eaton as long as it accepts and returns a valid entity
justafish Contemplate 2019 Edition
justafish :wink:
eaton *sob*
justafish but yeah, you could do that, we’ll have API endpoints
justafish so because we’ll be using those API endpoints, you can also use them and build whatever you like
eaton But that’s the dream — because that’s the part that is really frustrating in Drupal today, and a lot of FEDs would appreciate IME
webchick @eaton Sorry, which part?
justafish No Special Sauce(tm)
webchick The part where they just have to suck up whatever Drupal spits out, or?
eaton being able to roll your own React powered edit form for a given entity and replace the standard form
webchick Ah, gotcha.
eaton the “automagic” way is to composite React widgets together, the “fallback” is to composite classic FAPI widgets…
eaton and the “bespoke” way is to just munch up the JSON entity object, twiddle it, and send it back for validation
eaton would it make sense to have that tied to Form modes?
justafish hmm good point
eaton since that’s what drives the combination of widgets, and it could (conceivably) provide a convenient way for developers to build two separate versions of form for different scenarios?
justafish +1
justafish (This stuff will come when we work on Field UI, we can do permissions page without this)
eaton aye
eaton don’t mind me, just getting ahead of everything

@eaton has joined the channel

4️⃣ Does the JavaScript code-style cleanup work belong in the roadmap?

drpal Y/N
drpal _Please circle one_
justafish N
webchick I circle the slash :smile:
alexpott Not for me. Although I really hope to help us power through it.
dawehner I think this is a parallel effort
webchick But lean towards N… only because my observation has been that unlike going into this initiative where I was like “WOO! Let’s get all of those queued up and done in 2 weeks. Easy peasy” that doesn’t seem to be how they go. They seem to be more longer-term, gradual things that are going to (or at least have) extend through multiple releases. Therefore falls under general “maintenance” vs. “a product differnetiator”
dawehner I also think though that it would be nice to get someone else do these changes, so @drpal could review them
webchick These kinds of changes ideally would be where we point eager new contributors
webchick With the old guard doing reviews/mentoring
drpal > eager new contributors
webchick Vs. the old guard doing the coding + the reviewing + the arguing
drpal For JS, these people don’t exist.
justafish I wouldn’t point new contributors to our old codebase, it will scare them off :stuck_out_tongue:
webchick @drpal Don’t exist *yet* :slightly_smiling_face:
dawehner Sadly these changes are not as easy as just adding a dot at the end of comments
webchick @justafish haha, fair point
dawehner I think we should try to get existing contributors onto the JS sides
dawehner On the other hand we also talk about 6 remaining issues
lauriii I think if we really want to get this done, we should keep it on the road map
drpal @lauriii I agree.
webchick @dawehner No, I’ve reviewed a couple of them now, they’re quite intense and each line needs to be evaluated separately. Which again brings me to the question “What do we lose if we no longer attempt to do this and instead focus 100% on the new stuff?”
drpal It’s pretty close.
webchick Cos I’ve seen those issues suck 20+ hours from various contributors. I’d love those 20+ hours on newspangeldy stuff, personally.
webchick But I don’t quite understand what we lose if we go that way
alexpott Yeah as proves this is not simple. But also it is something I'm willing to help get done.
drpal @webchick The thing we loose, at the entire point of doing the code-style changes was so that we could turn on linting of our current JS.
dawehner @drpal well I think there is no reason to not be able to do that now
webchick @drpal I don’t get that though. We alreday lint our current JS. We just don’t maybe use the full set of rules.
drpal And then those of us doing reviews never have to check for code-style issues to our existing JS.
dawehner That's why we have made changes to the eslint file
drpal Sure, but then every patch will probably fail.
webchick IF we as a team (including committers present) think that this is something we could queue up and get done in 8.6, then I’d be ok with it going on the roadmap I guess.
alexpott Yeah at least the lint:core-js-passing proves we don't regress
webchick But if it extends yet *another* release (it’s already been on 2-3 of them afaik) then it’s just ‘maintenance’ imO
webchick And we don’t add maintenance work to roadmaps
drpal I personally would really like to not doing these code-style cleanup issues anymore.
webchick It also sounds liek we *don’t* necessarily want new eager contributors going at this, vs. we *do* want them going to github and making admin routes for things (presumably) so that’s another kinda questionable huh
drpal However, it would also be nice to actually start something and get it to completion.
drpal So there’s that.
webchick in terms of promoting it
webchick @drpal Right. Again, *if* it’s something that’s reasonable to get through to completion in <5 months, great. Let’s do it.
webchick But so far that hasn’t really borne out. And without finding and eliminating the reason/s for that, I’m nervous.
alexpott @drpal I promise to help get this done on the side I just don't think it worth blocking other valuable time on it. (i.e. yours)
drpal @alexpott Thanks. :+1::first_place_medal:
webchick Ok, added it to the roadmap as an 8.6 target, feel free to wordmsmith
drpal @webchick Yeah, there’s always been the review and commit cycle.
webchick Hm. It’s not “just” that though
drpal They take time, and there are fewer of us on the JavaScript side.
alexpott @drpal one down :slightly_smiling_face:
drpal @alexpott :clap:
drpal I have a patch for no-use-before-define and I can post tomorrow.

5️⃣ Spinning this off for design/UX specific discussion on permissions page and Field UI

justafish @ckrina do you have any thoughts?
webchick There are some old attempts at this… not necessarily relevant, but let me dig ’em up.
ckrina @webchick It would really useful :slightly_smiling_face:
webchick — This is something attiks was working on, proposed for core. Basically “inverts” the current model, where you *start* with the widget you want on the form, then fill in the data later. Was written based on usability studies at University of Minnesota (and really everywhere) where this is what 99% of users expect.
dawehner
webchick AFAIK it got quite far, but got hung up on relations vs. regular fields.
webchick What we might want to do as part of this is separate “data modeling tool” from “form building tool”, not sure. Because for people who do want to start from the data side of things, starting from widgets makes no sense. And there you want something more like the Mautic UI (which afaik dries has shown off in keynotes before)
ckrina Before jumping into design I think we'd need a list of _components_, like wireframes or similar to know which elements must be used there
webchick but for people wanting to build forms, they want something that looks a lot more like webform looks (or at least used to)
webchick
dawehner Contentful has something like a field UI:
ckrina yet another good solution from Contentful
ckrina Thinking on the design, there might not be something with a finished design soon, but having this priority can actually help a lot focusing efforts
dawehner I think having the entire flow in one screen is a great idea
webchick @ckrina Yep, maybe something we can bring up on tomorrow’s UX call?
ckrina +1 to that. Removing changes of context/page refresh is usually a good thing to do
webchick Also I promised I would bring Drupal sock puppets to that call, so… you have that to look forward to. :wink:
ckrina @webchick yess! :smile:
ckrina LOL

Comments

justafish created an issue. See original summary.

justafish credited alexpott.

justafish credited ckrina.

justafish credited dawehner.

justafish credited drpal.

justafish credited eatings.

justafish credited eaton.

justafish credited lauriii.

justafish credited mglaman.

justafish credited webchick.

justafish’s picture

justafish
she/her
Primary language English
Location London, UK
commented
Status: Active » Fixed
justafish’s picture

justafish
she/her
Primary language English
Location London, UK
commented
Title: Weekly Meeting - 2018/02/19 » [Weekly Meeting] 2018/02/19

Status: Fixed » Closed (fixed)

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

justafish’s picture

justafish
she/her
Primary language English
Location London, UK
commented
Title: [Weekly Meeting] 2018/02/19 » [Admin UI & JavaScript Modernisation Initiative Weekly Meeting] 2018/02/19
Project: Drupal core - JavaScript Modernization Initiative » Drupal core
Version: » 9.x-dev
Component: Meetings » meetings

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.