september 13, 2024 - Informator

Vilka av de 14 bör alltid ingå?
Det finns lika många svar som roller, produktfamiljer, eller applikationsområden. Michael A. Jackson (min forne arbetsgivare) kategoriserade applikationsområden i ett antal Problem Frames, som t ex operatörs- och övervakningsstöd, editorer (för text, bild, presentationer), styrsystem och automation, informationssystem, fil- och dataomvandling, osv.
När det klarnat vilket/vilka ”frames” som kommer att dominera projektet är det lätt att välja bland både diagram och metoder/processer/arbetssätt. I agil modellering är det syftet som avgör. I den vanliga jämförelsen med hus (där olika ritningar visar grund, byggnad, VVS, el, tele, bredband osv) fungerar Problem Frames även som arkitekturgrund. I en blivande ishall eller gym behöver man lyfta fram andra saker än i en villa, och på samma sätt blir arkitekturen för ett processtyrningssystem olik en editor.

Livet efter ITIL Foundation – En individ lär så länge hon lever, en organisation lever så länge den lär

ii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;”>

CSS selectors are evil and JS is the solution

rder-bottom-right-radius: 0px; border-top-left-radius: 0px; border-top-right-radius: 0px; border: 1px solid #cccccc; box-sizing: border-box; color: #333333; font-family: Menlo, Monaco, Consolas, ’Courier New’, monospace; font-size: 13px; line-height: 1.42857143; margin-bottom: 10px; overflow: auto; padding: 9.5px; word-break: break-all; word-wrap: break-word;”>h2 {


  font-family: Verdana;
  font-size: 14px;
}
.explanationBox {
  border-radius: 15px;
  padding: 10px;
  border: 2px solid springgreen;
  background-color: moccasin;
  color: magenta;
}
.explanationBox__headline {
  font-weight: normal;
  letter-spacing: 5px;
  padding-left: 15px;
  font-style: italic;

}

It is now slightly more clear what styles are applied where. Both the earlier questions are easier to answer, since we can do a search for the more precise class names.

But we still have the problem of the generic h2 selector. Also class names might be dynamically created and/or added to an element, so again, in a dynamic setting it might still be hard to find out exactly what’s going on.

Take 3 – inline styles in a React component

The basic idea in BEM, as well as in OOCSS or any of the other attempts at bringing structure to CSS, is to think in terms of components. All style definitions, as far as possible, should be tied to a certain component.

This jives very well with modern JS frameworks, who (almost) all have a component-centric architecture. If components are our main abstraction, then it is very easy to make an API to style individual components.

React (and most of the competition) does this by letting us provide a CSS-like JS object to the style prop:

const box = {

  borderRadius: "15px",

  padding: "10px",

  border: '2px solid springgreen',

  backgroundColor: 'moccasin',

  color: 'magenta'

};



const headline = {

  fontFamily: 'Verdana', // should live in generic h2 styling, but we're cheating for now

  fontWeight: "normal",

  letterSpacing: "5px",

  paddingLeft: "15px",

  fontStyle: "italic",

  fontSize: '14px'

};



export class ExplanationBox extends React.Component {

  render() {

    return (

      <div style={box}>

        <h2 style={headline}>{this.props.title}</h2>

        {this.props.children}

      </div>

    );

  }

}

Elsewhere in our React app we can now do this…

<ExplanationBox title="Did you know?">

  <p>Ozelots hate maccaws!</p>

</ExplanationBox>

…and we have our reusable, styled component!

Take 4 – imported inline styles

However, what you just saw was really nothing but a regression to our Take 0 attempt, where we put all styles inline. Like an animal.

But we can improve on this super easily, simply by migrating the styles to a separate file! Imagine the following living in a file named styles.js:

export const typography = {

  h2: {

    fontFamily: 'Verdana',

    fontSize: '16px'

  }

};



export const explanation = {

  box: {

    borderRadius: "15px",

    padding: "10px",

    border: '2px solid springgreen',

    backgroundColor: 'moccasin,

    color: 'magenta',

  },

  headline: {

    ...typography.h2,

    fontWeight: "normal",

    letterSpacing: "5px",

    paddingLeft: "15px",

    fontStyle: "italic",

    fontSize: '14px'

  }

};

Note the handling of the basic h2 styles!

Our React component now becomes this:

import {explanation} from styles;



export class ExplanationBox extends React.Component {

  render() {

    return (

      <div style={explanation.box}>

        <h2 style={explanation.headline}>{this.props.title}</h2>

        {this.props.children}

      </div>

    );

  }

}

We have now sort of reinvented the stylesheet! Except, where before the stylesheet used selectors to fire blindly into the dark…

…we now let the components go get exactly the styles they need via imports:

It might not be immediately obvious, but the flipping of this arrow makes a world of difference!

Finding the killer

Remember the first unanswerable question?

What styles are applied to this element?

In our imported inline style setup, this becomes trivial to answer. I simply follow the thread backwards from the style prop!

Finding the victim

Our second unanswerable question was:

To which elements are these styles applied?

Again, because of the explicit imports, this becomes very easy to answer (if you have a semi-competent editor):

LESS isn’t more

Through moving our style definitions to JS land, the need for CSS preprocessors goes out the window. Remember how we used the ... spread operator to mix in the h2 styles into our headline rules?

headline: {

  ...typography.h2,

  fontWeight: "normal",

  letterSpacing: "5px",

  paddingLeft: "15px",

  fontStyle: "italic",

  fontSize: '14px'

}

That was the equivalent of a LESS/SASS mixin! You’ll quickly find that the other syntax they give us can be easily replicated with pure JS. For example, having global variables becomes trivial:

export const palette = {

  softcolor: 'moccasin',

  hardcolor: 'magenta',

  accentuationcolor: 'springgreen'

}



export const explanationBlock = {

  box: {

    borderRadius: "15px",

    padding: "10px",

    border: '2px solid ' + palette.accentuationcolor,

    backgroundColor: palette.softcolor,

    color: palette.hardcolor,

  },

  // ...truncated

As do implementing helper functions to add vendor prefixes, saturate colours, etc.

Wrapping up

To recap; by turning the arrows around through using JS and inline styles, almost all opaqueness of regular CSS goes away. Previously difficult tasks such as…

renaming a CSS class
identifying and removing dead CSS code
hitting the correct elements with selectors
NOT hitting the wrong elements with selectors

…suddenly become easy or entirely moot.

While there are still a lot of questions to be answered regarding moving CSS to JS space, there’s no doubt in my mind that just being able to flip the arrow of responsibility makes it all worth it.

One of the primary downsides of inline JS styles is that we can’t use pseudoselectors such as :hover or @media. I hope to show how we can get around that using helper libraries in an upcoming post.

Dag: 13 september 2024

Agil modellering, kravkommunikation, Påskbord, smörgåsbord… Vad är lagom?