Drupal allows users to configure the name of the anonymous users. As part of #123 we added a hard coded anonymous user name. We should fetch the user configured anonymous username and use that instead of the hard coded one.

The anonymous user is stored in the user.settings configuration.

Because when I made this module it relied on internal classes 😞

This will be a separate set of tests from the ones that will be available in Drupal core, although it would be nice if the folder structure was the same so that core would also pick up these tests.

In Drupal, there is support for overriding markup / CSS coming from a theme, and/or massaging data prior to it being output, on a pretty granular basis (only for these content types, etc.).

We need to figure out if, and if so how, we support this concept from the React application.

Right now the routing/redirect is quite broken when you installed Drupal in a base path, like localhost:80/drupal

Currently we load all content on a single page which causes performance issues when there is lots of content. Add pager to the content list. The pager should be linked to work with the JSON API instead of paging content in the browser.

When there is no content as a result (because either non exist, or filters excluded them) we could offer a welcoming message to create some content with a link to /node/add

See https://www.drupal.org/project/drupal/issues/1798540

This is an issue to record things which would be good to go into a re-usable component library. These are things which require talking to Drupal in some way:

• File upload widget design issue
• Multiple items wrapper (For example N textfields instead of one)
• WYSIWYG fulltext field
• Vertical tabs

The current admin content table allows sorting by a table columns. This seems useful so we probably want to include this in our demo.

Deleting content works currently by redirecting to Drupal's delete content form. We could improve the UX by allowing deleting content directly on the app. Material UI has tools in place for this use case: https://material.io/design/components/dialogs.html#alert-dialog

When I follow the step on the main page, namely

composer create-project jsdrupal/drupal-admin-ui-demo -s dev --prefer-dist

After a time I get this response.

....

• Installing doctrine/common (v2.8.1): Loading from cache

• Installing asm89/stack-cors (1.2.0): Loading from cache

• Installing drupal/core (8.6.x-dev dc4fa9e): Loading from cache

• Applying patches for drupal/core
  https://www.drupal.org/files/issues/2018-04-11/2911319-2-191.patch (Provide a single command to install & run Drupal)
  Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2018-04-11/2911319-2-191.patch

• Installing drupal/jsonapi (1.15.0): Loading from cache

.....

So it looks like D8.6.x has been updated past the point at which 2018-04-11/2911319-2-191.patch is usable. And the patch needs a reroll

Can we eject from CRA and use the defaults it provides? I think long term we'll probably run into some configuration we need/want to change and that might be difficult.

I personally don't mind setting up and maintaining the build process, if thats something that is worrisome.

If we're planning to handle the admin experience of Drupal, one of the big parts of the admin experience is content listings. For example, admin/people, admin/content, etc.

We did a lot of work in Drupal 8 to ensure all of these things are Views, and can be customized by the site builder without any development.

I don't think we want to lose one of the hugest benefits of Drupal (Views) during the React-ification. How do we balance this?

Drupal consists of a large amount of configuration pages. Writing react components for all of them (as we do in PHP) would be a lot of effort without much gain

As outlined on drupal.org autogenerating those forms would be a nice solution.
This issue is about discussing an approach to the problem. Implementation will be done on top of that.

It could require a couple of steps:

• Configuration schema needs to be improved.
  1. In order to provide better UX we need to have some way of defining widgets. PHP and JS could then convert this into meaningful things
  2. access checking etc.
  3. many more, see https://www.drupal.org/project/drupal/issues/2949888
• We need to expose configuration schema somehow to the client. Either directly or indirectly using JSON schema. Given that config schema has concept of labels etc. already, using config schema seems more natural
• And then we need to actually implement such a UI generator
  • We could at least think in similar terms as https://github.com/mozilla-services/react-jsonschema-form
  • For each config schema type we could have a default widget, but then allow to specify a custom widget configuration, when a module author wants to.
• Finally we need connectors to fetch and post the actual configuration back.
• Generating configuration forms doesn't result into generating every form using this mechanism, as this would reinvent form api

Note: There is some experiment on https://github.com/jsdrupal/drupal-admin-ui/tree/config-experiment-2 going on. Please ping @dawehner if you want to play around with it. Setting this up is a bit tricky right now.

The PR #115 introduced some date formatting. This doesn't take into account users timezone configuration from Drupal, but instead falls back to using users browser settings. We should get the timezone configuration from the backend and format the date using that.

Based on discussions w/ core committers, it seems like it would be very advantageous to get everyone on the same page about what this initiative is attempting to do, plans on how/when exactly to get the work into core, how to handle major points of collaboration, work through some architectural questions, etc.

Front End United is coming up the weekend of Thursday, May 31 - Saturday, June 2, and has sprinting space available the weekdays prior (Monday, May 28 - Wednesday, May 30). Several key initiative folks are already planning to be there, along with committers such as Dries and Alex Pott.

So let's figure out:

1. What's the agenda for such a sprint?
2. Who's coming and when can they be there? (and/or participate remotely)

Here's a stab. I'm sure it needs lots of work.

Logistics

Sprint runs Tuesday, May 29 until Friday, May 1.
Location is at the co-working code sprints at Front End United in Utrecht, Netherlands: https://www.frontendunited.org/program/coworking-code-sprints
Address:
In de Ruimte
Oudegracht-Tolsteegzijde 230, 3511 NT Utrecht

Cost is €11.95 / day; tickets available at https://www.eventbrite.com/e/frontend-united-utrecht-tickets-40107668115 Apparently we are getting access to the space for free! :O Thanks, FEU! :D

Agenda

• Agreement on scope/timeline for initiative w/ Dries + other committers
• Work through architectural questions of various issues tagged Problems That Need Solving, ideally with outside expertise:
  • Views support / What should "site builders" be able to change: #15
  • What should themes be able to alter: #14
  • What should modules be able to alter: #13
  • Translation/localization: #11
  • Component library: #17
  • Routing: #12
• Dynamic loading of additional JS from modules?
• Hammer out plan for release management challenges:
  • Experimental vs. Stable
  • GitHub ❤️
  • Coordination with API-First initiative
• Next-generation admin UI designs, goals, and how to integrate with them.
  • Ideally we would be able to come up with tasks for people to get involved
• Flesh out roadmap for admin UI: release 1, release 2, release 3... and how/when to integrate upstream with Drupal.

(This seems like a VERY lofty list, so we probably want to prioritize it and focus on doing only a few of these things well.)

Who/when?

If you're planning to attend (remotely or in-person), please fill out your availability at https://docs.google.com/spreadsheets/d/1b73QHyqRKzbiL_sdAflnBCGLbLOghhdTq4VjnyQq7_0/edit?ts=5a9f9ba3#gid=0 under the "Drupal JavaScript Initiative / Admin UI" heading (~row 125).

FAQ

Do I need to buy a ticket for the conference?

webchick
@dawehner I looked into that, and no. However, you do need to buy daily tickets to the co-working space. Sec.

https://www.frontendunited.org/program/coworking-code-sprints

• Which Drupal paths are overridden by the app?
• Where are components exposed by routes in Drupal modules, so we can allow modules to expose custom routes?
• How do we communicate to the app which routes a user has access to?
• How do we communicate available items in a menu tree?
• Will we continue to have something like local tasks/local actions?

I saw that issue #7 mentions the "bonus" of a storybook story for the permissions page and #17 deals with components that are Drupal Admin specific.

I think it would be a good idea to

1. have a storybook style guide for this project to enable style development asynchronously to feature implementation
2. to create an architecture where we do not copy paste components between react-drupal-components and this project, but for example, require drupal-react-components as a dependency lib.

Then we can decide if a component like the Message component should also go to the more general Drupal components in the drupal-react-components project, where people with a Drupal background could use them for all kinds of React projects.

I think that would make a sustainable solution that would only need a bit of refactoring in the already existing components to make them compatible with emotion or other concepts of providing styles through passing in className as a prop.

The current quick-start environment is currently missing the path overrides for the /admin/content listing page.

https://www.drupal.org/project/jsonapi/issues/2960550

JS oriented summary: JSON API specifies a concept of 'links objecta'

These links objects are used to like to related resources.

If one retrieves an entity via JSON API, we could include a link to a resource which describes the edit form for that entity (for the current user)

The form representation could be JSON.

That JSON could be a special object describing schema, available fields (respecting field access), field settings, and possibly links to JS form validators.

API Endpoints Needed

• list of permissions
• Roles and Permissions (config entities) are available from JSON API

We're already going to be on the same domain as Drupal, meaning we can use Cookie authentication, so we can use the browser's fetch API directly for this.

Components Needed

• Table (with sticky header)
• Checkbox

Submit Function

I'm not sure if we can write the config entities through JSON API yet, so for now let's pretend it's making a successful request with an artificial delay

Permissions Page

Component skeleton is here, with ability to add CSS
See also https://github.com/jsdrupal/drupal-admin-ui/tree/master/src/styles for global styles

Jest Test

Can be added as an additional file in https://github.com/jsdrupal/drupal-admin-ui/tree/master/src/components/05_pages/Permissions

Bonus Round

It would be great to add Storybook to this project and add a .story file into https://github.com/jsdrupal/drupal-admin-ui/blob/master/src/components/05_pages/Permissions

Menu tree resource property subtree is an object when there are values, but an array when the list is empty. Currently, we are only expecting for an object type of values on this property.

Setup circleCI to build jsdrupal/drupal-admin-ui-demo automatically, so it will always work.

The roles UI is currently just accessible when you know the UI.

• Adapt Default.enhanceMenuLinks to includes a link to roles

The current "add content" button is added using local actions but we could probably for now just hard code the button. I think we could use the pattern from here https://material-ui.com/demos/buttons/#floating-action-buttons for this.

Right now there is no indication of a successful save.

#7

What about using the logo ◀️👋▶️ as favicon?

Tagged as novice task / help wanted

We are still missing the author name on the content list.

We might want to consider caching some data in the store instead of refetching everything on every route change. There are some examples such as current username, menu etc. that are quite easy to persist in the store but should be changed when mutations happen. Some more difficult cases are for example content listing and single pieces of content.

It would be nice to have some level of bulk operations, so you can publish multiple nodes at once.

Working on https://github.com/jsdrupal/drupal-admin-ui-support/pull/1 @dawehner @mattgrill and I were dicussing whether the permissions titles and descriptions should have the HTML stripped out on the server-side.

One thing to keep in mind is that eventually we would want core itself to provide these endpoints. So should make them now as they would likely be added to core?

• Describe how to setup a local dev environment:
• Configure cors

sites/default/services.yml

  cors.config:
    enabled: true
    # Specify allowed headers, like 'x-allowed-header'.
    allowedHeaders: ['*']
    # Specify allowed request methods, specify ['*'] to allow all possible ones.
    allowedMethods: ['*']
    # Configure requests allowed from specific origins.
    allowedOrigins: ['*']
    # Sets the Access-Control-Expose-Headers header.
    exposedHeaders: true
    # Sets the Access-Control-Max-Age header.
    maxAge: false
    # Sets the Access-Control-Allow-Credentials header.
    supportsCredentials: true

• Grant permissions: "administer site configuration" "administer users"

We should build a generic loading animation that could be utilized in different pages. For now this could be at least utilized on the content listing.

I was reading through what WP is doing for automated testing here:
https://humanmade.com/2018/05/17/automated-accessibility-testing-during-development/

Came across these react tool for accessibility:
https://github.com/reactjs/react-a11y
https://github.com/evcohen/eslint-plugin-jsx-a11y

Would be good to have better tools to test the builds.

Again, automated tests only go so far, but they are better than no tests.

Mike

Drupal worked a lot throughout the years to get a good localization support in PHP.
For example we do support pluralized strings properly: Every language has potential a different concept of pluralization (1, 2, 5, 10 for example).

Let's discuss in this issue which features we need and how to not move ourself into an edge case

Features we need | keep in our head

• String localization
• Do we want people to manage these strings through Drupal somehow?
• Proper string pluralization

Useful libraries

• https://github.com/yahoo/react-intl

It would be nice to have pager support for the content listing. Right now in core we prefer simple pagers, aka. "mini pagers" over full fledged ones for performance reasons.

Pager component in Material UI and a demo.

The pager should be linked to work with the JSON API instead of paging content in the browser.

Follow up of #7 (comment)

The admin theme is available on packagist now: https://packagist.org/packages/justafish/drupal-admin-ui

The install command will need to create a symlink (or create a copy) from vendor/justafish/drupal-admin-ui to vfancy

Consolidate the fetch calls we have into a central place

I do not want to open up a huge discussion on pros and cons, but I thought to bring this up early would make sense.
I personally am doing my first project that will go into production with Typescript and saw a definite improvement in code quality and safety. It was hard in the beginning especially with some more complex definitions in React for interfaces of some HOCs of e.g. react-apollo, but in the end, it really pays off especially when an application gets more and more complex.
Since this here will no doubt be a complex beast, I would recommend using Typescript over just defining PropTypes...

I would gladly help by refactoring the current code with https://www.npmjs.com/package/react-scripts-ts if we can agree upon using TS

The menu items are being loaded from the Drupal API after every location change.

Proposed idea: https://www.drupal.org/project/ideas/issues/2836165
Pre-requisites: https://www.drupal.org/project/jsonapi/issues/2931785
Core issue: https://www.drupal.org/project/drupal/issues/2843147

Having mulltiple repositories can be annyoing, especially when they need to be kept in sync.

Idea:

• Move https://github.com/jsdrupal/drupal-admin-ui-support into this repository
• Adapt https://github.com/jsdrupal/test-project to automatically link the module to docroot/modules

One of the larger questions around how this app will interface with Drupal is deciding what features of Drupal we will support.

One of the major features of Drupal that people love is its extensibility. An example of this is Form API, which through mechanisms such as hook_form_alter(), let you make per-module, or site-specific decisions about how another module's forms look and act. (Hiding a field for content authors, for example.)

Do we, and if so to what extent, want to support this capability in our React app?