Today I learned more about the distinction between declarative and imperative programming. I have seen the terms used in various places, but I could not give a good explanation about what they mean. So with a bit of curiosity and I thought that I would get a better handle on the definition.

Imperative programming is like how you do something, and declarative programming is more like what you do.

Today I learned how to control Tailwindcss. I am planning on using Tailwindcss on an upcoming project and in order to put something new like this onto a production website, I need to understand it deeply.

Tailwindcss out of the box

/* input.css */
@tailwind base;

@tailwind components;

@tailwind utilities;

// tailwind.config.js
module.exports = {
  theme: {},
  variants: {},
  plugins: []
};

# command
tailwind build input.css -o output.css

Putting the above together and running the command will output a css file that is 54309 lines of code and 854.59KB in file size! The developers talk about this on the official site and it is not the recommended way to use Tailwindcss. What I needed to know was what config settings could create a very minimal output that I could add to as I needed it.

Today I learned that sometimes a refactor is not always better, just different. I followed through with my plan to split my styles out into individual modules:

// Example styles module 'body.js'
import CustomTheme from "../../Theme";

export default {
  formBuilder: {
    paddingBottom: CustomTheme.spacing(8)
  },
  formBuilderContainer: {
    maxWidth: "770px",
    padding: 0
  }
};

That module sits in a /Styles folder, at the same level as my container component, and is exposed via an index.js file like so:

export { default as body } from "./body";

Today I learned I still don’t have a good answer when it comes to managing CSS-in-JS. Last time I discussed this topic I had decided to make a single Styles.js object that contained style overrides to Material UI. I consolidated all my components styles into that Styles.js file. Abbreviated example below:

import CustomTheme from "../Theme";

const Styles = {
  formPreviewContainer: {
    maxWidth: "770px",
    paddingTop: CustomTheme.spacing(8),
    paddingBottom: CustomTheme.spacing(8)
  },
  formHeader: {
    position: "relative",
    paddingTop: CustomTheme.spacing(4),
    paddingBottom: CustomTheme.spacing(4),
    paddingLeft: CustomTheme.spacing(4),
    paddingRight: CustomTheme.spacing(8),
    marginBottom: CustomTheme.spacing(4),
    backgroundColor: CustomTheme.palette.primary.main
  },
  // ... other styles omitted for brevity ...
  textInput: {
    "& .MuiInput-underline:before": {
      borderBottom: `1px solid ${CustomTheme.palette.grey[300]}`
    },
    [CustomTheme.breakpoints.down("sm")]: {
      width: "100%"
    },
    [CustomTheme.breakpoints.up("md")]: {
      width: "50%"
    }
  },
  textArea: {
    width: "100%",
    "& .MuiInputBase-input": {
      lineHeight: "24px"
    },
    "& .MuiInput-underline:before": {
      borderBottom: `1px solid ${CustomTheme.palette.grey[300]}`
    },
  }
};

export default Styles;

Today I learned how to do numbered pagination in my Hugo theme using golang. This was a bit harder than I expected as I am no expert on programming with golang. But once I remembered that golang still follows the same programming conventions that other languages do, even though the syntax is different.

After the posts in my theme, there is a simple navigation area at the bottom. At the moment it looks like this:

Today I learned to keep following my intuition.

TLDR Use woff, not woff2 for web fonts in email

I had been asked a question by our art director today about using web fonts in an email campaign that was being designed. The company we are designing for has a corporate identity that specifies certain font families. I had already begun to test this back in March so I had an idea of the state of web font support in email clients.

Before I answered him more definitively, I wanted to perform a few tests using our email marketing software — Campaign Monitor — to confirm what could be achieved.

Today I learned to really appreciate React Redux. I have used Flux like patterns only a handful of times. Mainly in Vue using Vuex. But it’s been a while since I last used one.

I am in the middle of building a prototype App in React and the “main” component was becoming unwieldy. It contained all the main state, all the functions that were passed to child components as props and the way things were going, it was about to become responsible for asyncronous data as well. That is too much for one component.