Reusable resizable flex HOC

[outoftime]

Adds a higher-order component that injects drag-to-resize flex functionality into any component with a draggable flex layout. All calculations and state are managed by the HOC, reducing a presentational component’s responsibilities to forwarding refs, using the flex values given, and delegating drag events back to the handler prop.

Unlike the previous implementation, the logic here follows a simple rule that dragging a divider will only affect the size of the regions adjacent to that divider. While there is no obvious right or wrong answer here, the new behavior is consistent with other drag-to-resize implementations I’ve played with, and makes it particularly easy to support an arbitrary number of flex regions. Anyway, the fundamental structure of this code could accommodate different logic, so it wouldn’t be difficult to refine in the future.

The initial flex layout of the regions is taken as a given, and should be set up using normal CSS rules in the stylesheet. This means that the resizing module makes no assumptions about what the initial size ratio between the different regions is.

Actual resizing is done exclusively by changing the flex-grow property to match the size ratio implied by the drag action, so the initial layout of the regions should use flex-grow as the primary means of sizing. The module explicitly prevents regions from being resized smaller than their “initial main size” (the size they would be without any flex grow or shrink), so a large flex basis with flex shrink won’t work.

This PR does not add any new flex resizing, primarily because the two areas where it would be most useful—the instructions bar and the console—don’t currently have the right DOM layout to afford it. Changing the DOM layout on top of everything that’s already in here would yield a substantially oversized PR. Anyway, the direct motivation for this change is a code quality improvement (encapsulating the flex resizing concern in a smaller number of code locations), which is accomplished by the changes herein.

To do

• Drop drag events outside of range
• Deal with hidden regions
• Move initial flex for editors container into stylesheet
• Generalize to rows or columns and apply to vertical divider
• Clean up HOC implementation
• Ensure we aren’t doing unnecessary render passes via HOC

[outoftime]

@pwjablonski Would love to get your thoughts on this! All feedback very welcome, but in particular I’m interested in whether this seems straightforward enough from an API consumer standpoint (e.g. would it be intuitive to use it to add flex resizing to more parts of the UI)

[outoftime]

This is a much nicer way to do what we need to do here, but it doesn’t currently work with connected components, so I wasn’t able to do this refactor for <Workspace>

[outoftime]

This change will make it substantially easier to decompose <Workspace> into several smaller presentational components, but that should come in a separate PR.

[pwjablonski]

Hey @outoftime sorry for the delay here! This is awesome! From a consumer standpoint, this looks pretty straightforward to implement. That being said, I can't say that I 100% understand what is going on underneath the hood (in src/util/resizableFlex.js) but would be comfortable to implement on another set of resizable components. Also there are a couple of things that I need clarification on, mostly for my own edification. See comments.

Also had a couple of errors logged to the console.

1. forwardRef render functions do not support propTypes or defaultProps
2. isExperimental Failed prop type in topBar and hamburger
3. projectKey Failed prop type in instructions

[pwjablonski]

This is very clear - allows for 2 resizable containers in the workspace component.

I don't fully understand how connect works and how/why passing both resizableFlex(2)(Workspace) here works.

[outoftime]

@pwjablonski good question. The basic situation here is that resizableFlex is a function that returns a function that returns a component. So, calling resizableFlex(2) means “make me a function that takes a component, and decorates it with a controller for a size 2 resizable flex container, returning the decorated component”. Then calling that function with the Workspace component as an argument gives us the actual decorated component.

Does that clarify?

Also occurs to me that this PR really needs some tests. In particular I am wondering if the inner workings of the resizableFlex module may be a bit easier to understand with the aid of some unit tests. Of course I should also add tests for the new reducer.

[outoftime]

OK @pwjablonski updated with some tests and some mildly improved code organization. Take another look? Would love to know if the implementation is any clearer now that there are some unit tests, and do let me know if there are specific areas that don’t make sense!