Design Modes API Thoughts

design_modes.js

MyApp = SC.Application.create({
  modes: {
    phone: 350,
    tablet: 900,
    desktop: Infinity
  }
});

MyApp.MyView = SC.View.extend({
  
  labelView: SC.LabelView.extend(SC.AutoResize, {
    layout: {
      default: { left: 0, top: 0, height: 30 },
      phone: { centerX: 0, top: 0, height: 30 }
    }
  }),
  
  inputView: SC.TextFieldView.extend({
    layout: {
      default: { left: 0, top: 40, width: 300, height: 30 },
      phone: { left: 0, right: 0, top: 40, height: 30 }
    }
  }),
  
  cancelButtonView: SC.ButonView.extend({
    layout: {
      default: { left: 0, bottom: 0, width: 100, height: 30 },
      phone: {
        portrait: { left: 0, right: 0, buttom: 0, height: 30 }
      }
    }
  }),
  
  saveButtonView: SC.ButtonView.extend({
    layout: {
      default: { right: 0, bottom: 0, width: 100 },
      phone: {
        portrait: { left: 0, right: 0, bottom: 40 },
        landscape: { right: 0, bottom: 0, width: 50 }
      }
    }
  })
  
});

notes.md

Note how the label view and input view have differing modes for desktop/tablet/whatever and for phone, but the button views take it one step further by also saying that it should care about portrait mode.

In the cancel button's instance, it only cares if it's phone AND portrait. If it's phone AND landscape, it uses the default properties. However, in the save button's instance, it has properties for both portrait and landscape.

At the moment, these are the only things that I care about, and I imagine other are similar. In general, we don't care about the actual aspect ratio, just when that aspect ratio switches from landscape to portrait.

This is nice. You can't use default though, that's reserved. The way that I had it before was that layout was the default and if there was a mode, this was applied as an adjustment onto the default. It made it easier to just nudge values without having to specify the whole layout for each mode. Something like:

layout: { top: 10, width: 200, height: 200, right: 10 },
designAdjustments: { phone: { top: 0, right: 0 } }

Maybe we can add the adjustments within layout though? I'm not sure if that's better or not.

I definitely like the designAdjustments approach much better!

Here in my opinion is the key test that our API has to be able to pass.

There exists an app with a header bar at top and a toolbar at the left, surrounding a main content area.

There are two width-based modes: when wide, the lefthand toolbar is always visible; when narrow, the toolbar shrinks to a collapsed click-or-swipe-to-open mode.

There are two height-based modes: when the window is tall, the header bar is broad and has lots of navigation content. When short, the header bar collapses to a shorter version.

The main content area then has four different layouts: large top gap / large left gap; large top gap / small left gap; small top gap / large left gap; small top gap / small left gap.

Whatever the API we end up with, it's easy to include handling for optional portrait / landscape tweaks per your work above, but how do we handle the main content area's need for four different layouts along two different axes?