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 @ :flag-us:
lauriii Lauri @ :flag-th:
mrjmd Another Matt @ :flag-us: :slightly_smiling_face:
drpal Does anyone have any topics for today?
prestonso Preston @ :flag-us:
lauriii I’m back from almost 4 weeks of holidays so I don’t have any topics :flip:
mrjmd No topics, mainly here to hear more about the latest progress, and excited to see the new components repo.
justafish Sally :wave:
dawehner Hallo, German living in London
webchick Hey, folks. Angie from Vancouver, Canada. :slightly_smiling_face:
drpal @webchick :wave:

2️⃣ React UI Component library

drpal I’ve been working on this on and off since the very end of last year,
mrjmd :beers:
drpal It’s incredibly rough.
lauriii creating a README with some information about contributing instructions and purpose of the repository could be helpful :innocent:
drpal Eventually.
drpal There’s obviously a lot of things left to work on.
drpal More components, better documentation + examples.
drpal How do we handle styling.
drpal Do these match core or something else?
drpal Or is everything unstyled.
prestonso @drpal this is really awesome — could you give an example of how some of these components would fit together in a real-world use case?
dawehner @drpal This is a tough question. I think for now it would be easier to make progress by skipping the styling for now
drpal @dawehner I :100:% agree there.
prestonso @dawehner @drpal I agree, but I wonder if there should be some styling in a future-state demo and whether it makes sense for that to be Seven
drpal @prestonso Imagine you want to create a user interface, and you’re using React. These components can help you get started with that.
prestonso @drpal got it — I was thinking more in regards to something like the dblog page — I'm interested in how the components can nest in one another
dawehner I'm mostly thinking about how would we make admin theming not impossible
dawehner And I'm not sure inline styling would make it easier or harder
drpal @prestonso Some of these components support ‘children’ some don’t, obviously its difficult to know that without any docs :stuck_out_tongue:
prestonso @dawehner @drpal I worry that with an unstyled demo it won't be very aesthetically pleasing, and the vast majority of React demos look half-made to my designer eyes :smile:
prestonso @drpal :thumbsup_all: :smile:
dawehner @prestonso We still inherit CSS from seven
prestonso awesome!
prestonso I should have probably prefaced that by saying I haven't had a chance to play around with these components :joy:
drpal @prestonso A lot of these components offer the ability to pass your own classes if you want to match the styles of an existing theme.
prestonso Sweet deal!
dawehner I'm curious whether we could have some sort of styleguide we work with
prestonso @dawehner you mean for React components in Seven? or for unstyled React components?
dawehner @prestonso good question. For me react components styleguides are also about interaction, not just styles
prestonso @dawehner
> are also about interaction
+100
drpal And that term get super muddy when talking about it in the context of a react component.
drpal Does it just accept some props and render data?
prestonso it seems we could either 1) write a style guide which includes designed interactions for Seven, 2) find one that has both, or 3) come up with our own bespoke
drpal Does it manage it’s own state?
drpal etc.
prestonso I would think those questions get answered by the designs in the style guide, not vice versa
webchick What is the plan to get those from GitHub into core?
drpal @webchick The component library?
webchick yep
drpal None right now.
webchick Like. Get the library done in GitHub first, attempt to add it wholesale, pick N basic components and add those as a start, along with a patch that puts them into use in ____ admin UI, etc?
webchick In some ways it seems like the earlier that we get feedback on the general approach, the better off we’re gonna be vs. spending weeks or months of time before the first non-team core developer sees it and has feedback that leads to all kinds of ripple effects
webchick Interesting that this is valid code:

link = <span {...restProps}>{children}</span>;

No quotes or nothin, huh!
lauriii JSX ftw!
drpal @webchick Yeah, JSX.
lauriii this is one of the things many people were complaining on the React issue :smile:
webchick Yeah. It’s interesting that it takes us back to the D5-era before we had template files, of embedding markup (which is one specialty) with JS code (which is another)
webchick Quite different than Twig. Wonder how that’s gonna fly.
webchick Anyway, it’s probably not worth pursuing this in the core queue until after the alpha crunch, but probably shouldn’t wait much longer than that if we want to target these components (or a subset thereof) for 8.6.
drpal @webchick I think we’re going to stick with JSX.
webchick Right, I understand that’s the “Reacty” approach
drpal If we don’t, and we don’t want to use JSX with React, there’s huge hurdle we have to overcome.
drpal It’s not trivial to drop JSX.
webchick It’s just verrrry different than all of our other front-end code in Drupal right now, so… we should be prepared that others will make that observation. ;D
drpal I think they did.
drpal In all of the +1 for my framework of choice comments.
webchick I think what the first patch will probably need is a “demo” of some kind that puts the these components into practice on some UI so that people can understand how it’s going to play with the render system, theme system, etc.
webchick Does DB log still make sense for that, or..?
webchick @drpal Well. That’s the subset of the audience who knows what JSX is. The vast majority of your audience doesn’t even write JS. :smile:
webchick So be prepared for another onslaught of OMGWTFBBQ is all I’m saying. :slightly_smiling_face:
drpal > The vast majority of your audience doesn’t even write JS.
drpal Exactly.
webchick But these components are still *for* them, are they not? Like to build UIs from?
webchick Same as the vast majority of our audience isn’t Form API maintainers, but they can still use #type => textfield
dawehner If someone sees non JSX used in react in Drupal they will turn around and run away
justafish @webchick well that won’t change, the vast majority of people will never touch these files
webchick Sorry, to be clear! Super not advocating for NOT using JSX.

More trying to come up with a strategy for making this improvement palatable to the masses given the above.
dawehner I mean seriously, let's assume we want to teach anyone react and say: Yeah in our case everything is different though, that doesn't sound convincing
justafish #type => textfield renders you a react component and you don’t have to think about it/do anything new
webchick Which is why a “demo” is important, so it’s like “Yes, this looks like ugly D5-era code. But all you need to type is <womp womp> and voila. you get a search box” or whatever.
webchick So is there a page that makes sense to “component-ify” as part of the patch?
webchick Table drag or something?
webchick @justafish oh, well that’s lovely if that’s how it works.
webchick But won’t “old school” render API and “new school” React components be living side by side in D8 at least?
webchick Or are we thinking this is a one-shot, “convert ALL renderables to React components in one go” kind of patch? That seems steep. :confused:
justafish probably - we have to split apart the form api
dawehner For me there are two usecases: a) I want to customise my form A LOT b) I want to have a more or less simple form without customisation
dawehner For b) we should not require people to use react at all (at least for now)
webchick @dawehner can you map a) to an actual use case in core? Would it be somewhere where there’s a lot of gunk (styling + actions + state changes + whatever) lumped together? Like Toolbar or Tabledrag or..?
dawehner @webchick Good question, let's say the field UI
dawehner This has a lot of internal state, actions, styling etc.
webchick Ooof. Can we pick one that we already don’t want to replace with literally anything better? :smile:
webchick Block visibility?
webchick I guess that’s not fancy enough.
drpal It doesn’t have to be fancy.
webchick Views UI? :scream:
drpal > Yes, this looks like ugly D5-era code
drpal This is only slightly insulting.
webchick @drpal Sorry, I don’t mean it to be insulting, trying to be realistic about what kinds of React™ions to expect from PHP devs who’ve never looked at React (which is 90%+ of core developers)
webchick And who just spent 8+ years separating markup + business logic in the form of HTML template files.
webchick This is why coupling a handful of components with a use case, that ideally shows “well THAT’S a lot simpler” is helpful.
webchick And probably the sooner the better, so we can find out what React™ions are, and separate the “wahhh change is horrible bahhhh” from “Hm, valid point.”
webchick Like. We picked React because we wanted to do $new_cool_thing. Where’s a place in core we can do $new_cool_thing and show off its strength? Let’s introduce components that way.

My 2 cents. :slightly_smiling_face:
justafish I think the effort required to get to that point is being underestimated
justafish and React/JSX is somewhat inconsequential by the time we get to that point
justafish like, that’s the easy part!
drpal That’s what we learned from the DB Log prototype.
drpal React was the easy part.
dawehner Yeah like: We need components, that's a concept outside of react
justafish and we need Drupal to control those components
webchick Oh, THAT could definitely be true.

I guess what I’m worried about is I see a GitHub full of components. And will presumably be added to over time. And get bigger and bigger and bigger.

And at some point we want to propose those components for core. And that’s going to require an initial patch. And the makeup of that initial patch will make a big difference in how much of an emotional sewage drain that issue ends up being.
justafish well!
justafish I think they’d be better staying on GitHub
justafish pull them in with composer
webchick So I am trying to strategize about what that first patch should look like, but perhaps this is FAR too early for such a thing.
justafish I think it is
webchick I’m sensitive to the fact that it’s 7 days before alpha and everyone is losing sleep and meals and family time to get their shit in and I would rather that not repeat here for 8.6. :smile:
dawehner I think we should emphasize what really matters isn't the markup, its the separation of components we want ... Do we want one menu component, or do we want to have a component for each menu link so you can customize them
webchick @justafish so maybe my question is wrong then, and the right question is more “What’s the next step for the ‘use React on admin UIs in Drupal core’ initiiative”?
justafish focus on the issue that Tim started imo
webchick Is it just an issue brainstorming what Daniel just talked about? Getting some agreement on the “granularity” of components we need as a first step? A “blueprint”?
justafish (sorry I’m on another call atm, don’t have it to hand :slightly_smiling_face: )
webchick K, I will try and research that. :slightly_smiling_face:
lauriii I think it’s also about what kind of modularity will we allow
webchick If anyone has the link handy tho, hit me. :smile:
lauriii I think that’s the big question
justafish I think we’re not close to that either. Right now we don’t have a form API where the presentation is separated from other stuff
justafish we need it to spit out some json that we can read and turn into a component
justafish which in this case will be React, but whatever really :slightly_smiling_face:
drpal
webchick Gotcha. :slightly_smiling_face:
drpal This is the form issue from @tim.plunkett
lauriii It is really difficult one, even the Mozilla project haven’t got it fully right
webchick I guess my only cautionary tale then is the further you develop “off the reservation” the more risk you introduce when this stuff does inevitably reach the core queue, the better chances of having to do major, painful refactoring, the higher chance of burnout on all sides, etc.
lauriii I mean the main problem has been that defining UI in JSON can be really difficult
webchick So even if we had an issue to talk about this at a “pseudocode” level, soon, that would be really good.
dawehner @lauriii Well, we could say that we limit the usecases to a subset of what is possible with all the power of fapi right now. Would that help?
webchick Ooooh
webchick That would be nice. Sidestep that whole wasp’s nest :smile:
lauriii Probably yes, but we would have to agree that it might not be possible ever
webchick Cos I’m guessing some of the fun stuff with handing off render API => theme system => react or whatever is going to rear its ugly head with even just a “block title” component.
dawehner @lauriii The full featureset? I think even if it would be possible it would be a waste of time
lauriii agreed that we shouldn’t try to build a clone, but also there might be some useful things that will be difficult for us to implement
dawehner @webchick Yeah I think we should not try to enlarge the scope of dealing with the render API, but rather keep inside the form system and otherwise really rely on JS components
webchick One idea I had floated to @drpal on a call between he and I a few weeks ago… a new experimental module called “tablefilter” or something, that exposes a set of react components for doing those boring admin listings with a filter box at the top.
tim.plunkett There are obvious things to agree upon. Like the need to have `'#type' => 'status_report'` work in any form (to render the entire site status report) is not an 80% use case :smile:
webchick And then exposes a dynamic Db log page as a controller
lauriii most likely this will lead some of the logic being moved from PHP to the UI (JavaScript)
dawehner @lauriii I remember the discussions around leveraging symfony forms instead of FAPI and one major point was that they relied more on templates for anything presentational, so maybe we should set the cutoff point there
webchick because this would be a) something useful, b) something optional, c) something uniquely requiring JS
dawehner @tim.plunkett Is status_reports a form at this moment in time?
lauriii it is a render element :stuck_out_tongue:
tim.plunkett @dawehner `\Drupal\system\Element\StatusReportPage` and `\Drupal\Core\Render\Element\StatusReport` are both render elements, for some unknown reason
dawehner ¯\_(ツ)_/¯
webchick hahahahaha
webchick that’s awesome
lauriii I think it was due to BC problems
dawehner Well, let's be honest, if we talk about a 1to1 relation between render elements and react components this would make sense
lauriii we did it on the major Status Report re-design
dawehner @webchick So your tableflip idea, would that improve the UX of these particular pages?
webchick @dawehner I mean, if we had a modules page-style keyword filter above every long table? I think it would.
webchick And that’d get into some of the data binding aspects, which from what I understand is a big reason why you use react.
dawehner I think implementing another listing page (just like DBLOG) would totally help to find common patterns we want to put into components.
webchick Yeah, that’s the goal… and even start with just finishing DBLog, and this could be a v2.
webchick I’m basically SUPER keen on introducing this general idea to all D8 initiatives:
webchick
webchick So what is the “skateboard” of this initiative? I thought it was DB log, but maybe it’s something else.
dawehner It is a bit tricky because we already have a motorcycle, now we though try to build a hoverboard
webchick hahaha
dawehner As in: Just rebuilding exactly what we have in core right now could not be seen as much of progress overall
webchick Right, hence the “make it jazzier” aspect of “with a filter box!”
webchick And maybe then eventualy “with sortable table headers, oooohhhhh!”
webchick This is difficult because it’s a little “blind leading the naked” here… I don’t know what all React can do to know where best to utilize it in Drupal’s UIs.
webchick But I’m very interested in helping to solve the “pick a use case” problem, so we have an “in” and can get started as soon as possible showing tangible results.
dawehner That's the thing I'm a bit confused about. Core has all that already. You can filter by tet, you can tablesort
webchick Right, so would react-ifying those components net us any code sanity?
webchick Else, if we want to pick a “new” UI, most likely candidate for 8.6 would be Media Library. Could probably do quite a lot with that.

But I’m a bit nervous to take a struggling initiative and combine it with a brand new initiative…

Hence, can we simplify / make better / etc. one of the existing UIs?
webchick OR, if other people have other great ideas on how to start introducing React to core, I’m all ears.

OR, if I should STFU and let you guys just work, that’s fine too. :smile:
dawehner @webchick The media UI is a good one!
dawehner @webchick But yeah I see your fear
dawehner For me a major UI improvement would be adding a filter to the permission page
webchick Sure. We have a feature request for that from the 5-digit node ID days I think. :slightly_smiling_face:
dawehner This is certainly more one of the special pages, not generic form pages
webchick @dawehner so a “tablefilter” React component, apply it to modules page+ permissions table as a patch?
justafish you still don’t have a mechanism to provide these components through Drupal, and I think you’re being extremely optimistic thinking that’ll bein for 8.6
justafish :sad-panda:
dawehner @webchick I would personally like to see an experimental module you can enable and replaces the existing thing, so people can try it out
webchick @dawehner yep, makes sense. and the path to stable could just be overwriting the component in misc/ with the react one instead.
webchick @justafish I guess in my mind, the mechanism to provide componets through Drupal would be part of this patch.
webchick It’s just a “use case-driven” framework change vs. a framework change on its own.
webchick Layouts is having a lot of success with a “mega patch” that is “here’s what we’re trying to do” and then various sub-issues split off for “make a block that renders fields” and “decouple layouts from this thing” and whatever.
dawehner @webchick Oh yeah totally just rewriting something for the sake of it really doesn't make sense
justafish right, this feels like pushing short-term goals for a demo that isn’t ultimately very useful
justafish like we could go and ship the dblog demo right now, but tbh it’s kinda useless
justafish you can’t control it, override it
justafish reuse it etc
webchick @justafish like I said, totally open to other ideas. Just trying to spitball how we enter the Golden React Age™ without a body trail. :slightly_smiling_face:

What is your plan/vision?
justafish and these are all things which need to be controlled within Drupal
dawehner @justafish So do you argue we should talk more about short/mid/longterm goals?
justafish ok so, we can’t create a React app that’s the admin theme like Calypso because that would basically mean we’re saying “we don’t do themes anymore, we’re just an API”
webchick Is that where we ultimately want to get to, tough
webchick though*
webchick ?
drpal It’s where I personally want to get to though.
dawehner See that's a hard question :slightly_smiling_face:
justafish one thing that people have said a lot, is that they don’t want to have to learn 2 languages in order to generate a form
drpal If you want to ‘theme’, you can make a new react application using different components, or your own.
justafish so they need some kind of FAPI that will spit out React components
webchick I’ve heard that request before from the Ember folks.
webchick (For a FAPI for JS)
justafish which Mozilla have been working on
webchick right.
webchick But won’t work for our use case because of reasons I don’t recall atm
justafish if you look at something like Keystone CMS, they auto generate their admin theme
justafish based onJSON
dawehner But that's why they also have really simple UIs
webchick Iiiiinteresting
dawehner There is a tradeoff between generic and customization
justafish right, so in order for this to be useful to anyone outside of a handful of core devs, people need to be able to actually use the components
dawehner @justafish Would in this world someone still interact with FAPI?
justafish so we could replace the dblog page with what we have, and that’s a nice demo, but for any Drupal developer it’s not relevant to them
justafish it just ends up as lots of single page apps scattered across the admin theme
webchick @justafish right, the idea of DB log is “skateboard” only.

Because I’ve seen too many inititives tinker in their garage trying to build a motorcycle for years while WordPress comes out with a fucking Lexus in the meantime. lol
dawehner @justafish Which to be fair could add a lot of UX improvements for the users
webchick So my idea wasn’t “skateboard” as end game, it was “let’s see how many tools we’re missing just building the skateboard”
justafish sure, but when you want to improve the UX of something which actually matters to most people e.g. field API, it’s not useful
webchick But ideally this would fit into a larger plan to build the lexus
webchick @justafish So is THAT the goal of this initiative? Tackle Data Modeling?
justafish I think so
justafish building React components is cake
webchick We can also go that approach. We just have no designs for what that looks like, and need to build them.
webchick (and bikeshed them and etc.)
justafish allowing Drupal developers to say “I want an autocomplete field here” is useful
webchick Which is why Media Library would perhaps be a nicer target because there’s both a spec and EVERYONE understands how a media library should work
webchick However, I’m not sure how to skateboard that one. Need to ponder.
webchick And definitely DO NOT WANT to introduce more instability into that initiative by coupling their stuff to an unproven (in core) technology, so it’s risky.
justafish the thing about the single page app replacing the entire admin theme
justafish is that module authors will want config pages etc for their stuff
webchick OTOH we have to quit creating “betamax” UIs at some point here if our goal is to “mp3" the shit out of everything
dawehner @justafish Do we talk about simple configuration?
justafish so you still need that piece which says “here is how a form should render”
justafish tl;dr we need this for Drupal
justafish so back to Tim’s issue… :joy:
webchick @justafish I really, really think we need to be approaching this in parallel from a “how do we put a non-form React component in core” way too tho. :confused:
dawehner @justafish So we want people to still write PHP?
webchick That Tim issue could very easily take until 2020 to solve
justafish @dawehner that’s what people have told me!
webchick PHP developers want to write PHP. JS developers want to write JS. Requirements gathering is fun. :smile:
webchick JS developers DO NOT WANT to learn PHP. PHP developers will sometimes learn JS.
dawehner As a developer I would ideally not write code at all, aka. the system generates forms for me
webchick @dawehner that’s my stance as well. :slightly_smiling_face:
justafish on the blockchain
webchick LOL
dawehner Let's put Drupal into VR
justafish :facepalm:
webchick Ok, so back in this plane… :wink:

So @justafish does not like the DB Log example cos it’s a silly PoC example that does nothing useful for end users.

What if we picked a different example that was useful to end users, but didn’t require figuring out how to re-create the fucking Form API in JS? :stuck_out_tongue:

What was the name of Wim’s module that made comments and stuff appear without page refreshes?
webchick
dawehner @webchick I think rewriting the frontend was out of scope
webchick That was it
webchick Right, so only do it on the admin UI.
webchick Add a new role/user and it instantly appears.
webchick Fuck, still forms though. BAH
justafish Drupal is basically a form generator :stuck_out_tongue:
webchick Well wait. Is it? Or is it just capturing the #redirect?
justafish one thing we could do
justafish is start a new FAPI
justafish that only deals with React components
dawehner admin/modules admin/people/permissions are non forms things
justafish well, sorry, not React components
justafish only deals with spitting out JSON
justafish don’t try and backport the old one
dawehner @justafish But is limited in its featureset?
justafish right
dawehner It could itself internally on the PHP side (for serverside validation) fallback to the old fapi
webchick @justafish and use it to generate standard config pages? (e.g. admin/settings/foo)
justafish @webchick yeah
justafish @dawehner I wouldn’t complicate it
webchick I mean, there’s a whole host of bullshit we will uncover in that exercise, so that seems good on its face.
justafish I’ll build my own FAPI! With JSON and a limited feature set!
webchick hahaha
dawehner @justafish Well, reimplement the complex security model is a non trivial task, why not reuse what we have, but purely internal
webchick I’m already wondering how the heck you’re going to perform validation consistently between PHP forms and JS forms, for example. :slightly_smiling_face:
webchick Let alone all of FAPI’s tricksy checking to ensure that the options you submitted were actually in the original list, etc.
justafish @dawehner I don’t know, this is your area of expertise, I’ll trust you on that one then :wink:
dawehner Implementation details though., sorry
justafish but the idea is that you can’t mix them
dawehner But yeah we should talk about: What should be possible for a PHP developer to control in a JS UI
justafish you can use the current FAPI for all it’s stuff, or the new one
webchick @justafish so the goal of 8.6 would be… “As a ___, I want to ___ with a ___.” What use case would be satisfied?
dawehner @webchick One way to deal with that is to actually use REST and its internal validation
webchick +100 for that. :stuck_out_tongue:
dawehner "As a developer I want to retire with a farm"
justafish lol
webchick That is at least 50% of why I’m excited for this initiative. :slightly_smiling_face:
webchick LOL
webchick No, is it… “As a JavaScript developer, I want a JSON representation of Drupal’s admin forms, so that I can create a simple form myself using web components?”
webchick or..?
justafish As a PHP developer, I want to describe the structure of a form, and get a cool React powered form generated for me
webchick NICE
webchick That’s exciting! :slightly_smiling_face:
justafish and As a JavaScript form developer, I want a JSON representation of a form so I can create a cool React powered form
webchick And then for the “demo”… what? Is there something that would really show off a “cool React-powered form”?
dawehner Maybe the point is to not have cool demos :slightly_smiling_face:
justafish lol
webchick Cool demos are what get people excited about your initiative and stopping bikeshedding about stupid shit that doesn’t matter. :slightly_smiling_face:
dawehner Just show that ```admin/config/system/site-information``` works in JS without further work from the developer
webchick I love that we’re basically recreating system_settings_form() in JS :smile:
webchick I loved that fucking function
webchick @dawehner So, PHP developer defines a form in PHP? JSONFAPI turns it into JSON? SettingsApp renders it as a form?
justafish :+1:
webchick Cool. :slightly_smiling_face:
dawehner Yeah, a lot of boring forms!
webchick Haha, will they look/behave exactly the same? Is there something that will be more “Reacty” about them?
webchick “You can see Drupal use crusty old Arial while React is all *Helvetica Neue*! SWANK.” lol
justafish @webchick i think has some good examples
justafish in the readme
webchick Oh fuck, this demo is reminding me that this FAPI is going to have to deal with accessible errors, too.

Egads. You guys have your work cut out for you. :wink:
justafish (sorry still in meetings atm!)
justafish @webchick well I don’t think we’d be trying to have server-side fallback or anything ambitious, so that isn’t so daunting
dawehner @webchick I think we should be able to iterate and add accessibility etc.
dawehner @justafish While we don't need to necessarily have serverside rendering, we will need to have serverside valiation,I assume?
webchick Yeah, I agree with iteration.

I still have no idea how security/validation works consistently but that’s a problem to solve either way.
justafish the nice thing is that ‘type =>’ can be literally anything
justafish it’s up to the client what it does with it
justafish I think someone mentioned this as an example earlier
justafish so you can be like ‘type => dblog’
dawehner Well its both nice and not nice at the same time
justafish and then the client can decide to make some badass single page app db log
webchick Right, type => dblog doesn’t seem overly helpful. type => big-ass-table-of-data-with-sortable-table-headers does
justafish yeah totally
justafish dblog is a good example though
justafish because you can just be like ’f it, gonna make a fantastical UI for this”
webchick I *really* want to see a fantastical UI for DB Log
justafish something that’s not going to try and be re-usable
dawehner @justafish Yeah i agree. At the end if you want to provide good UIs overabstracted generic UIs don't cut it
justafish right
webchick <-- 404
- 403

:smile:
dawehner Which is the more traditional Drupal approach
justafish some stuff will be useful and shareable, like sortable tables - and some stuff just won’t
justafish in which case, override it and do whatever you want
webchick Sure.
justafish so
justafish I think you want 2 demos here
dawehner Yeah I mean no question, a generic table showing actual data no question, but then you start to actually put interaction models into it
justafish 1. A module author wants to create a config form
dawehner Like you know, in DBLOG a badass feature would be to actually see the full error message and its variables, like inline opened when you click on it
justafish 2. A module author wants to create magical db log
webchick @dawehner yep.
webchick That was my “skateboard” concept with DB Log. not “DB Log as you’ve always known it, yawn” but “Actually USEFUL DB log with tons of cool dynamic features that oh BTW are generic components and can be used on ANY admin table”
webchick (sorry the ANY admin table would probably be motorcycle but you get the gist ;))
dawehner @webchick Well I believe that a kickass DB log would not result in a resuable table component
justafish which is why we need the second “simple” demo alongside it
dawehner But I think for module authors it would be really nice to have a nice admin table to use
justafish so show that we’re not just creating spin off apps for everything
webchick @justafish+1
dawehner @justafish ```/admin/structure/views``` a list of available views. Its a boring listing, would that work as as second simple demo?
justafish what about /admin/content ?
dawehner I don't think /admin/content is really that simple
webchick Admin/content is a form
webchick lots of filters and checkboxes and whatnot
dawehner Yeah given its a bulk form, so you can apply operations on your content
justafish ok, yeah
webchick This is also why Permissions isn’t ideal, even though it’s TOTALLY ideal. :stuck_out_tongue:
justafish your suggestion is good :+1:
webchick Ok, so… to summarize… possibly…
dawehner @justafish One natural followup: How would views be able to register a react thing, so it wouldn't have to do all the SPA setup stuff
webchick Oops, nevermind. :smile:
dawehner @webchick I think to summarize:
dawehner 1️⃣ Continue iterate on the Dblog example to enhance the UI to something better as we have right now in core
dawehner 2️⃣ Provide a second simple example to be able to identify more reusable compoents
dawehner 3️⃣ Continue thinking about providing a Drupal PHP <-> JS form thingy
webchick Do we need a sprint for #3? That feels ike the kind of thing that would greatly benefit from whiteboards and whatnot.
justafish probably
justafish :stuck_out_tongue:
dawehner Let's be honest, we just want to cuddle dodger (tim's dog)
webchick Who would be in attendance in an ideal world where funding and schedules weren’t a problem?
drpal I think this plan is pretty great.
justafish :hand:
drpal :hand:
justafish yes, we do all want to cuddle dodger
dawehner :v:
justafish gotta run, bbl!
prestonso I would love to be there to cuddle dodger and hangout with you all but I might not have much to add :joy:

3️⃣ JavaScript Messages

drpal Literally everyones favorite.
drpal
drpal @lauriii Now that you’re back, if you have time it would be great to start this review again.
dawehner @drpal Can you describe the current state of things?
lauriii ohh I’ve missed your comment fully
lauriii @drpal I think your comment makes sense
drpal @lauriii :pray:
drpal @dawehner The state is, we were waiting on review, and @lauriii made some great points and I fixed a thing related to error messages.
drpal The best part about JS messages, IMHO, is that it tries really hard to not make any assumptions about where your messages will go.
drpal And, if you are not actually including the library, nothing will happen.
prestonso +1 to nothing happening when I don't want it to :joy:
dawehner @lauriii Nice point 1!
lauriii @drpal I left a comment
dawehner Do we have ```Object.assign()```?
drpal @lauriii You mind if I update the existing change record I already created for this.
lauriii @drpal I’d prefer having separate change record for the template change (different audiences)
drpal @dawehner No, you’ll need a polyfill for that right now.
drpal Since there is no IE support at all.
dawehner IE<3
drpal
drpal @lauriii I can make that new change record then today.
dawehner It still confused me to have this messages API handle actual DOM level stuff, but I guess I'm just used to something different
drpal @dawehner Ha, yeah.
drpal @lauriii
lauriii @drpal looks good, maybe just a small code example of how to make the change to their template?
drpal :thumbsup:
drpal You mean you want me to make a twig example.
drpal _RLOLOLOLOL_
drpal @lauriii How about including an existing implementation as an example? Like from stable?
lauriii @drpal yeah something like that would work
lauriii @drpal looks great now :sparkling_heart:
drpal Wonderful.
drpal Real time collaboration, who would of thought this works well.
drpal :stuck_out_tongue:
lauriii @drpal can you find someone to do a final review, I can commit it then
drpal @dawehner @justafish Either of you have time?
drpal I can ask internally as well.
dawehner @drpal I'll try to give it another in depth look later tonight. Still in the office though
justafish @drpal poke me later in the week, first day back at work today for me :slightly_smiling_face:
drpal > Still in the office though
drpal Not sure I will ever get used to that :wink:

Comments

justafish created an issue. See original summary.

justafish credited dawehner.

justafish credited drpal.

justafish credited lauriii.

justafish credited mrjmd.

justafish credited prestonso.

justafish credited tim.plunkett.

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/01/08 » [Weekly Meeting] 2018/01/08

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/01/08 » [Admin UI & JavaScript Modernisation Initiative Weekly Meeting] 2018/01/08
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.