operation-condor.ts

/* 

Concern 1: CUSTOM STYLES

Custom theme styles are given to us as json.
Object has one level of nesting, mostly grouped by the component w/ some higher level blocks like 'global'.

We are not allowing free reign custom styles, but highly targeted element+property styles.

We should have global 'theme color' properties so you don't need to specify the same color in 10 places.

Properties do not always translate 1-1 w/ css properties.  E.g. we may have a `columns: 1, 2` that sets multiple css properties.
*/

const customStyles = {
  global: {
    bodyTextColor: '#000',
    headingTextColor: '#000',

    // Maybe we want primaryBackgroundColor, secondaryBackgroundColor?
    // In that case the semantics should be clear, e.g. primaryTextColor and primaryBackgroundColor will always be paired together
    // and secondarTextColor and secondaryBackgroundColor will always be paired together.  That way you can pick good color contrasts.
    //
    // It must be simple in js to compute color contrast, we should do that and warn in the admin if its a bad combination.
    backgroundColor: 'blue',

    // Hopefully a single format like woff will suffice for all clients.
    //
    // The admin UI for this could be picking from a list.
    fontUrl: 'xxx', 
  },

  // Thinking that we wouldn't actually provide low level styling on things like button. 
  // Instead it would pull in global bg/text colors, and things like hover could be derived
  // by calling something like darken(color, .2).
  button: {
    borderColor: '#000',
    backgroundColor: '#333',
    textColor: '#fff',
    hoverBorderColor: '#000',
    hoverBackgroundColor: '#333',
    hoverTextColor: '#fff',
  }

  // Styles targeting a component.
  // Again we could pull in colors from the globally defined set.
  // _If_ we do allow defining colors here, would it use logic like `header.textColor || global.textColor`?  I assume it would.
  header: {
    logoImageUrl: 'https://s3.amazonaws.com/playbook-us/public/images/scrimmage-logo-dark-c1869233523eb39e3be4aa0913f71b2c52c6f954f76ab7b89d5eebdd33c8279d.svg',  
    backgroundImageUrl: 'https://s3.amazonaws.com/playbook-us/public/images/background-texture-light.png',
    gradientTop: '#ccf',
    gradientBottom: 'fff',
  }

  //
  // !important! 
  // The admin UI must be able to preview what the screen will look like.  We must keep that in mind when building
  // the components.  E.g. they take in props that tells them how to render but delegate the behavior up.
  //  E.g. clicking the answer button will delegate to an object like QuizUI which handles the logic of updating state.
  // In the admin UI, we can have a NoopQuizUI that logs out 'you clicked buttonX!' but doesnt do anything.
  // Getting storybook in place soon will help with this, as that basically mimics how admin would work.
  // 
  // !!subtle note!! Embedding a preview of quiz ui in the admin would mean that our component designed and implemented
  // here would be dropped on a page w/ other styles.  E.g. it could have an unexpected reset.css, or the admin .css could
  // define a `.header` element as well that clashes with our.  This implies we may need to be more verbose in our .css names
  // or use the babel scoped class plugin to avoid that main clash.  That would still leave us succeptable to inheriting styles
  // we don't want, e.g. reset.css/normailze.css styles we didn't expect.  I was looking into scoped css styles and it looks like
  // thats been removed from the 'web platform' but people say you can use custom elements to achieve the same thing, and be
  // 100% isolated from the page's styles.  Not in IE but we can dictate the browser support for admin, where parts of quiz player
  // could be embedded.
  // https://caniuse.com/#feat=custom-elementsv1

  otherComponent: {  }  
}



/*

Concern 2: HOW ARE BASE STYLES WRITTEN

The styles that are built in to our app.

Should *not* contain any colors or images.  
The reason being, if in admin they override half of the color properties but don't pick the rest, we don't want the UI to be a mix of 
their colors + defaults.

If we want a 'default scrim theme' that can be a function of the admin app, e.g. the defaults are stored as json there and passed to quiz
ui.  That keeps things simpler for quiz ui, and it forces us to maintain our public api.
*/


/*
TODO fill in this section with your proposal.  
I don't have a strong feeling here, since custom styles are a restricted set and don't directly translate to css, I feel less strongly
about our base styles written as .ts objects as well since we can't just merge the custom styles in.
Probably simpler is better.
e.g. Single base.css or per component components/Header/Header.css or base.ts or per component components/Header/styles.ts or styles w/in components/Header/Header.ts
*/



/*

Concern 4: HOW ARE BASE STYLES PROCESSED

Only applies *if* we choose .css for concern 2.

Do we run them through postcss?  
I am thinking not, our browser support list will be good enough I'm not worried about bugs.
And being able to take advantage of newer features or language extensions like css variables or custom media types has low value imo,
especially in a simpler app.

Do we run them through the babel scoped react style names plugin?
See subtle not about embedding above.
Catches typos in classnames and styles going dead, adds some complexity though (e.g. mixing w/ unit testing).
*/

/*
Concern 4: HOW DO STYLES MAKE IT IN TO THE P

Propose how the custom styles make it in to the page, as well as the base styles.

I am thinking since custom styles are very restricted, and don't coorespond 1-to-1, so generate .css in an 
inline <style> block doesn't make sense.  Just reference inline like:
  
<button style={{ color: custom.button.textColor }} />
  
For how base styles make it in to the page, if we write as css its simple, webpack will pull them in as a single .css file to import 
(or can even inline <style> for performance).
  
For ts though, they could be merged together on the elements style attribute, though we have debugging concerns with that.
Dom inspector is too noisey, can't tell whats base and whats custom without tracing down source.

Assuming base styles map 1-to-1 w/ an element and its css props, could easily iterate over them and insert an inline <style>
tag just using the .thingsName { ... } as the class.  COULD EVEN DO THIS STEP IN WEBPACK AHEAD OF TIME!!!!!
*/

Embedding a preview of quiz ui in the admin would mean that our component designed and implemented
// here would be dropped on a page w/ other styles. E.g. it could have an unexpected reset.css

We could intentionally host the embedded preview as a CORS iframe. This would scope the JS and the CSS.