[JIMT][CT-510] code bridge dynamic layout

[thomasoniii]

As with all things CodeBridge, this is a WIP. The PR looks big, but is mostly just shuffling a few things around. git may have tagged files as being deleted/added that were merely moved. CDOIDE.tsx is the only thing with any really appreciable changes.

This PR retools the layout completely. The old layout container had a concept of left-pane, center-pane, right-pane, and allowing certain components to be showed within them based upon boolean toggles which were handed into the config when the component was vivified. It worked and had some view configuration options, but was still very limited.

This new flavor replaces all of CDOIDE's layout with a grid using grid-template-areas, which are now read in through the config.

For example:

const myConfig = {
  gridLayoutRows: '100px 32px auto',
  // gridLayoutColumns : is not provided in this config
  gridLayout: `
    "instructions instructions preview-container"
    "side-bar     file-tabs    preview-container"
    "file-browser editor       preview-container"
  `,
}

That gives us a 3x3 grid layout with the instructions across the two upper left pieces, the preview-container across the entire right side, a side-bar (which doesn't do anything anymore atm) and file tabs across the middle, and then the file browser in the lower left and editor in the lower center.

By changing the grid layout, we can completely change the UI/UX. WebView2 now has a Configure Layout button to more easily change these layouts to experiment with.

What do we need to do to really finalize this:

• I think we should move towards the CDOIDE to be a much more generic box component that accepts components for layout purposes. We should probably end up with a very generic LayoutGrid that just accepts components and grid-areas and then simply arranges them. Then the layout tools won't just be limited to CodeBridge.
• This doesn't really support the concept of dynamically resizing an area. We could hack in drag bars between grid areas to do it, but it's probably going to be messy. More layout type components using flex boxes would probably be better.
• We don't have a defined way to communicate between components, and especially not in a generic fashion that any arbitrary external component can use. We need to define that more robustly.
• BUT we shouldn't necessarily do it this way with grid-template-areas. There higher level packages out there that do what we do here and more, such as https://github.com/react-grid-layout/react-grid-layout. We should look into those and confirm the functionality we want and what best provides it.
• We should not necessarily expose all of this functionality to the user. While everybody loves a super configurable interface, it also tends to be overwhelming to the user and can cause a lot of confusion. Using this as an internal tool for prototyping purposes, or to generate a few canned layouts will probably be better, since the user won't actually need this level of flexibility. That said, internally I think we can really make use of it.

Links

• spec:
• jira ticket: CT-510

Testing story

Deployment strategy

Follow-up work

Privacy

Security

Caching

PR Checklist:

• Tests provide adequate coverage
• Privacy and Security impacts have been assessed
• Code is well-commented
• New features are translatable or updates will not break translations
• Relevant documentation has been added or updated
• User impact is well-understood and desirable
• Pull Request is labeled appropriately
• Follow-up work items (including potential tech debt) are tracked and linked

[molly-moen]

looks good to me, just some clean up comments

[ebeastlake]

General question: Should we support this level of configurability if we think the main scenarios we want to test are a vertical and horizontal console? It seems like it'd be nice to shorten the list of what we need to do to really finalize this.

[thomasoniii]

General question: Should we support this level of configurability if we think the main scenarios we want to test are a vertical and horizontal console? It seems like it'd be nice to shorten the list of what we need to do to really finalize this.

Yes, we absolutely should support this level of configurability, but no we should not necessarily allow end users to access it.

In fact, I'd probably strongly lobby against end users (especially students) to have access to this because the UX will probably be poor - it'd introduce too many variables to them and options to screw things up, in addition to making it more difficult for teachers and our helpdesk to aid them. The first troubleshooting step in such systems is always set it back to the default.

But having more flexibility in how we set up and configure layouts internally is nothing but a win. Same system under the hood, but not building configuration UI (or building configuration UI and only allowing certain users to access it). Giving our internal users flexibility to easily play around with layouts to get what they want w/o needing to involve lengthy dev changes is a big win.

[ebeastlake]

Resolved feedback offline! Excited to be able to test horizontal and vertical consoles.