DEV Community: Ryan Lanciaux

AI Generating a 3d Print

Ryan Lanciaux — Mon, 09 Dec 2024 18:27:25 +0000

Quickly take an AI generated image and make it a 3d print with the following steps.

Generate an image
Make the image a 3d model
Translate the model to something 3d printer software understands
Print (after coloring the model optional)

Generate an image

Use Flux or some other image generator to create an image. Be sure to include something like "Video game concept art pure white background" or "bright green background" to have the ability to remove the background easily.

Use Convert the image to a 3d model

I used TRELLIS to generate a 3d model from my image.

Translate the model to something a 3d printer can understand

Most slicer software needs stl or 3mf (although many can import from other file types). You can use a tool like Image-to-STL or open in Blender and export as STL/3mf.

Print the Model

Now you should be ready to print your model. I re-colored it in Bambu Studio, as I wasn't able to figure out a way to keep the colors intact through the filetype translation process.

And the result

Let me know what you think.

A couple tips for working from home

Ryan Lanciaux — Wed, 05 Aug 2020 12:22:19 +0000

Many developers have been tossed into remote work due to the pandemic. While it's quite a lot different than what remote work is like without an epidemic, it's great that technology allows developers to work while staying safe.

I've been working remotely in some capacity for over seven years. A couple of things I try to do to help remote work go as smoothly as possible:

Communicate A LOT but in the right medium e.g. Don't send a giant feature proposal over your messaging client. My rule of thumb here, if it's something that needs to be referenced later, it goes into something less timeline based (JIRA / Confluence / Docs / whatever)
Eliminate distractions If you have a personality where you get side-tracked easily, put your phone in another room. Use tools to help you block sites that you waste time on, etc.
Write down your daily goals and execute on them Some people do this by creating personal calendar invites for their tasks, TODO lists, or writing things down in notebooks. I do a combination of TODO lists + calendar items for tasks. It's okay if things need to change but writing down your goals is an excellent way to be mindful that you're changing your goals intentionally, instead of drifting into what you focus on.
If possible, keep your work equipment in another room I totally get it's not possible for everyone, but I find it helpful to have a space where I use my work equipment and mostly use it only in that space. This helps me keep some boundaries between when I'm working and not.
Get outside (if possible) I like to both take walks and otherwise exercise. I notice on the days I do this I'm both more productive, and generally feel better.

I'd love to hear your tips in the comments or on the following Twitter thread. Be sure to check out the thread for more:

// Detect dark theme var iframe = document.getElementById('tweet-1236298297532452865-314'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1236298297532452865&theme=dark" }

Add a visitor count on your GitHub profile with one line of Markdown

Ryan Lanciaux — Thu, 16 Jul 2020 14:04:41 +0000

In a previous article, I wrote about how you could add a visitor counter to your GitHub profile with a little node/express app. The article suggested that if you wanted to add a counter to your GitHub profile, you could copy and run the code on your own server. I've recently updated this operation to be a lot easier.

// Detect dark theme var iframe = document.getElementById('tweet-1283755637126705152-380'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1283755637126705152&theme=dark" }

You can now add a counter to your GitHub profile with the following line of Markdown

![Visitor Count](https://profile-counter.glitch.me/{YOUR USER}/count.svg)

I'd love to know what you think!

Quick GitHub profile visit counter

Ryan Lanciaux — Mon, 13 Jul 2020 13:05:44 +0000

UPDATE:

For those that don't want to run their own server, be sure to check out a quick guide to add a visitor counter with one line of markdown.

GitHub profiles are a great addition to the platform. These profiles allow you to highlight your experience/interests and supply a little bit of personality to what people see when they visit your profile. There are quite a few guides on creating a profile, but for those who may not have jumped into that just yet, you can add your profile by creating a new repository that matches your GitHub username. Any edits to the README.md file will show up when people vist github.com/{your_user_name}

Website Counter

I wanted to see if I could make my profile look a little bit like a website from the 1990s. A big part of any 90s personal website is the visitor counter. We can create a fun (and not necessarily accurate) counter pretty quickly using node and express. I ended up using Glitch for mine, but this concept should work on any platform that supports node.

Take a look at my GitHub profile to see this in action.

Node / Express project

The entire code for this project is posted below (or in this GitHub gist, or where it's running on Glitch). There are a lot of practices that we'd either want to avoid or clean up if it was for more of a production application. The key here is something that could be accomplished quickly for fun.

Tracking visits

From a high level, this application has a variable that records visit counts, an endpoint that responds to count.svg and updates the visit counts. Additionally, the count.svg endpoint should generate and respond with an image based on the count.

const express = require('express')
const app = express()

const PLACES = 7;

// no db - so global var to keep track of count
let counter = 0

function getCountImage(count) {
   ...
}

// get the image
app.get('/count.svg', (req, res) => {
  counter++;

  // This helps with GitHub's image cache 
  //   see more: https://rushter.com/counter.svg
  res.set({
  'content-type': 'image/svg+xml',
  'cache-control': 'max-age=0, no-cache, no-store, must-revalidate'
  })

  // Send the generated SVG as the result
  res.send(getCountImage(counter));
})

const listener = app.listen(process.env.PORT, () => {
  console.log('Your app is listening on port ' + listener.address().port)
})

Tracking visit count

We're using the global counter variable to keep track of visits. When a request comes in to count.svg, we update the global counter variable and generate an image.

// set up the counter variable
let counter = 0;

...
app.get('/count.svg', (req, res) => {
  // update the counter on any image request
  counter++;
  ...
}

Generating an image

I created an image in Sketch and copied the results as SVG and pasted it into the getCountImage method. The image was dissected a bit and rebuilt using our count value.

You'll notice in this function, we're switching the count to a padded string, and then into an array. This allows us to show the zeros before the count with the specified number of PLACES. const countArray = count.toString().padStart(PLACES, '0').split(''); From there, we build the count squares part of the image by reducing the array into a single string, and then referencing that in the svg.

Reduce can be a bit tricky to follow at times, and could often be replaced by a more standard loop construct. In this case, we're saying, iterate through all the array elements and append this new svg section with what came before.

function getCountImage(count) {
  // This is not the greatest way for generating an SVG but it'll do for now
  const countArray = count.toString().padStart(PLACES, '0').split('');

  const parts = countArray.reduce((acc, next, index) => `
        ${acc}
        <rect id="Rectangle" fill="#000000" x="${index * 32}" y="0.5" width="29" height="29"></rect>
        <text id="0" font-family="Courier" font-size="24" font-weight="normal" fill="#00FF13">
            <tspan x="${index * 32 + 7}" y="22">${next}</tspan>
        </text>
`, '');

  return `<?xml version="1.0" encoding="UTF-8"?>
<svg width="${PLACES * 32}px" height="30px" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
    <title>Count</title>
    <g id="Page-1" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
      ${parts}
    </g>
</svg>
}

Wrapping up

Ideally, we would want to persist our count to ensure that if the server restarts, the count values picks back up where we left off.
This could be something like a database record, or simply writing to a file. For this example, I don't care too much if I lose the count as it's mostly to achieve the 90s design aesthetics :D

The full code is available in this GitHub gist, or where it's running on Glitch.

Additional references:

I started off referencing an analytics example by Flavio Copes available here. In this example, Flavio created an svg that would collect website visit counts as a simple alternative to Google Analytics.

This article on the same topic by Artem Golubin was really helpful in determining how to adjust the HTTP headers to work with GitHub's image caching. GitHub has an excellent feature that anonymizes browser details from images to help prevent tracking called Camo. Without adjusting the HTTP headers, the image would not update upon new visits.

Better testing with Storybook

Ryan Lanciaux — Fri, 14 Feb 2020 19:57:08 +0000

In this article, we will discuss strategy that I like to help keep Storybook stories up-to-date. For those that are unfamiliar, Storybook is a UI component workspace that I find helpful in building front-end applications.

It allows you to develop your components in isolation, interact with these components individually, and see quality issues at a much more granular level than the screen or page level. Additionally, this workspace serves as communication to other developers, noting the reusable components that exist in a system. Learn more about Storybook here.

One criticism I often hear is that it's easy for a Storybook project to get out-of-date when developers forget to add their components to Storybook. I often find that Storybook speeds up development but understand the tendency to build new components in the context of the live, running application. It's easy to forget about adding stories when you have an otherwise working and tested feature.

How do we keep this "building components in isolation" mindset top-of-mind in a way that provides immediate value to others may not necessarily develop their components in Storybook first? In this scenario, I often like to treat stories as part of my testing strategy.

Traditional Testing

Let's assume we are building an activity feed. On our activity feed item component, we want to ensure that we're rendering the correct text, and the button onClick event fires as expected. We could use react-testing-library to establish confidence that our component is working as anticipated.

We'll use the render utility to render the component that we wish to test. We'll check the text and onClick functionality to ensure that everything is working.

// ActivityFeedItem.js
export default function ActivityFeedItem({ name, text, onClick }) {
  return (
    <Card>
      <Heading>{name}</Heading>
      <Text>{text}</Text>
      <Button onClick={onClick}>See Details</Button>
    </Card>
  );
}

// ActivityFeedItem.test.js
import { render } from '@testing-library/react';
...
it("shows the correct text", () => {
  const { getByText } = render(
    <ActivityFeedItem
      name="This is the heading!"
      text="Nostrud tempor ullamco aute nostrud commodo cillum amet ad velit veniam officia minim."
    />
  );

  expect(
    getByText(
      "Nostrud tempor ullamco aute nostrud commodo cillum amet ad velit veniam officia minim."
    )
  ).toBeInTheDocument();
});

When we run our tests, we'll see that all is working as expected.

Test Suites: 7 passed, 7 total
Tests:       9 passed, 9 total
Snapshots:   5 passed, 5 total
Time:        2.62s
Ran all test suites.

Debugging failing tests

What happens if our test is failing, and we want to dive in to debug?

Test Suites: 1 failed, 6 passed, 7 total

There are a couple of options but, one I use a lot is the debug utility from React testing library. This utility illuminates the HTML for the rendered element.

We could update our test as follows to leverage debug:

const { getByText, debug } = render(
  <ActivityFeedItem
    name="This is the heading!"
    text="Sit enim irure pariatur nostrud id non deserunt laboris veniam velit."
  />
)

debug()

The debug utility will log the HTML for our components. This strategy would work well for our trivial example component, but on a more substantial component, this can get unwieldy pretty quickly.

Instead of defining our elements to render directly in our test, we can leverage Storybook stories for this. We'll use stories written in Storybook's component story format to serve as the element we wish to render in our test.

We'll create the story metadata first. This metadata provides information to Storybook about how we should display our stories within the utility. Next, we'll create a story with the component story format. You may notice that we're creating an arrow function, which is not unique to Storybook. We can export this arrow function and import it in our test.

// ActivityFeedItem.stories.js
export default { title: "ActivityFeedItem" }

export const standard = (callback = undefined) => {
  return (
    <ActivityFeedItem
      name="This is the heading"
      text="Nostrud tempor ullamco aute nostrud commodo cillum amet ad velit veniam officia minim."
      onClick={callback}
    />
  )
}

Using the story in our test

Before where we rendered our component in the test, we'll use the imported story instead. Now, if we want to debug our test, we have a story we can use in addition to the other debugging strategies we may traditionally use.

import { standard } from "./ActivityFeedItem.stories"

it("shows the correct text", () => {
  const { getByText } = render(standard())

  expect(
    getByText(
      "Nostrud tempor ullamco aute nostrud commodo cillum amet ad velit veiam officia minim."
    )
  ).toBeInTheDocument()
})

We now have a way to visualize and interact with the component we're testing.

Wrapping up

Storybook provides many benefits beyond testing, but sometimes it's easy to forget when we're trying to get features out the door. I've found that using Storybook as a tool to help ensure quality helps avoid this situation where stories become out-of-date or neglected.

Optional Chaining in JavaScript

Ryan Lanciaux — Fri, 31 Jan 2020 07:15:03 +0000

In this article, we're going to take a quick look at the new, Optional Chaining operator in JavaScript. This language feature is valid JavaScript as of ES 2020 (the official definition of the language).

To take a look at why I think this feature is compelling, let's assume we have an object that represents a menu for a conference meal plan. Each object represents a different day for the conference and each day can have breakfast, lunch, and dinner.

const monday = {
  menuItems: {
    breakfast: {
      items: ['Eggs', 'Oatmeal', 'Cereal']
    },
    lunch: {
      items: ['Sandwich']
    },
    dinner: {
      items: ['Cheeseburger', 'Salads', 'Tempeh Sandwich']
    }
  }
};

const tuesday = {
  menuItems: {
    breakfast: {
      items: ['Cereal', 'Bagel']
    },
    dinner: {
      items: ['Tacos']
    }
  }
};

For our example, we'd like to console.log the first element of the lunch object. We'll display "No lunch on this day" for any day where lunch is not specified (and therefore not provided). We'll start with the following code.

function logLunch(day) {
  const lunchItem = day.menuItems.lunch.items[0];

  console.log(lunchItem || "No lunch on this day");
}


logLunch(monday);
logLunch(tuesday);

This function works well for Monday, but fails for the Tuesday object since it only specifies a breakfast and dinner. Typically we could solve that by ensuring our properties exist before interacting with them. In this case, our expression could look something like this:

const lunchItem = day && day.menuItems && day.menuItems.lunch && day.menuItems.lunch.items && day.menuItems.lunch.items[0]

It's not very pleasant to guard each property like this!

Optional Chaining

Thankfully, we can rewrite this line with Optional Chaining to the following:

const lunchItem = day?.menuItems?.lunch?.items[0];

We're using the ?. instead of a . between properties. This ?. is the optional chaining operator. This entire expression will be evaluated as undefined if any of the properties are null or undefined. Instead of checking these properties, we can express the desired intent much more cleanly with this new operator.

Check out the example for this article on Codepen.

I'd love to know of any thoughts you have. You can find me on Twitter here!

Nullish Coalescing in JavaScript

Ryan Lanciaux — Wed, 22 Jan 2020 07:15:03 +0000

Nullish Coalescing is a language feature of JavaScript that was recently promoted to Stage 4 by TC39, the group that maintains the definition of JavaScript. This means that this language feature is valid JavaScript as of ES2020.

With any language feature, it's good to understand how it helps us. Nullish Coalescing helps us eliminate a certain class of code that primarily consists of checking if something is null or undefined.

Lets take an example where we want to display a Star Wars character's first and last name. When the last name is undefined, we should show "Not Specified", but if the last name is "" we should treat it like the character doesn't have a last name. (noting that if this was not example code we would probably want to implement different logic for this)

For instance, if we had the following character definitions:

const hanSolo = {
  first: 'Han',
  last: "Solo"
};

const chewbacca = {
  first: "Chewbacca",
  last: ""
}

const rey = {
  first: "Rey",
  lastName: undefined
}

Lets assume that we had a function, displayName that was responsible for obtaining the character's full name for display.

We may be tempted to reach for a logical OR operator like follows.

function displayName(character) {
  const lastName = character.last || "Not specified"

  log(character.first, lastName)
}

This would work well for hanSolo and rey but would fall short for Chewbacca, since we're specifying that his last name is "" (meaning he has no last name for our simple example). The "" is evaluated as falsy, so the logical OR operator would evaluate to "Not specified" in this case. This fails to meet our requirements because a lastname of "" should not cause the displayName function to append "Not specified"

Without the null coalescing operator, we'd generally have to check for lastName being null or undefined since an empty string is evaluated as falsy.

If we change our function to the following, everything works as expected, however, it's a bit more code.

function displayName(character) {
 const lastName = character.last === null || character.last === undefined
  ? 'Not Specified'
  : character.last;

  log(character.first, lastName)
}

Using the nullish coalescing operator is a lot more focused:

function displayName(character) {
  const lastName = character.last ?? "Not specified"

  log(character.first, lastName)
}

This is very similar to the function using the logical OR "||" except we're using two question marks instead "??" View the example for this article here.

Please find me on Twitter at @ryanlanciaux

Snowpack with React: An awesome way to build web applications

Ryan Lanciaux — Tue, 14 Jan 2020 07:15:03 +0000

In this article, we're going to build a React application using Snowpack. Snowpack is one of the technologies I'm most excited about right now. It's a little bit like bundler in that it's responsible for preparing an application's third-party dependencies for use on the web but it has enough differences to make it a compelling tool to explore. Instead of building every time you save your code, Snowpack can do it's work after you install a dependency. Lets take a look. (The demo application we'll be building in this article is available here)

Getting started

We're going to create a new project. Instead of starting our project with Create React App, Gatsby, Next, etc. we're simply going to create a new folder, cd into that folder, and run npm init

> mkdir snowpack-demo
> cd snowpack-demo
> npm init

Once that's complete, we're going to install a couple of development dependencies. We'll start by including snowpack, followed by @babel/core, @babel/cli, and @babel/preset-react.

> yarn add --dev snowpack
> yarn add --dev @babel/core @babel/cli @babel/preset-react

Traditionally, we could run snowpack through npx but we'll be using snowpack's babel plugin a little later in this example.

Why Babel?

Speaking of Babel, you might be asking yourself why we're using Babel with Snowpack. This is a totally valid question as Babel is usually not required with Snowpack.

We're going to use JSX with our application. Unfortunately, the browser would have no idea how to handle JSX, so we're going to use Babel to help translate our code into something that the Browser can understand. Additionally, since we're using already using Babel, we're going to use Snowpacks's optional Babel plugin that will allow us to used named imports rather than importing by URL. What this means is traditionally, with Snowpack, we'd import React and ReactDOM like this.

import React from "/web_modules/react.js"
import ReactDOM from "/web_modules/react-dom.js"

With the (optional) Babel plugin, we can import our modules in a way that may be more familiar if we're used to things like Create React App, etc.

import React from "react"
import ReactDOM from "react-dom"

Behind the scenes, we're still using the files in the web_modules directory created by Snowpack. The Babel plugin is translating the name to this path for us.

Include React

With that out of the way, we're going to add React and ReactDOM to our project. Currently, React doesn't support ES Modules. Fortunately, some in the community have a version of React that we can use that does support ES Modules (as noted in the Snowpack docs).

yarn add react@npm:@reactesm/react react-dom@npm:@reactesm/react-dom

Now, if we run yarn snowpack we can watch Snowpack perform some work against our included modules.

> yarn snowpack
✔ snowpack installed: react, react-dom [0.79s]
✨  Done in 2.03s.

We can take a look at our web_modules directory and see that Snowpack created files for our newly included modules and an import map that we could use for browsers that support them.

> ls web_modules
import-map.json
react.js
react-dom.js

Next, we'll add live-server, the tool we'll use to serve our files locally.

yarn add --dev live-server

We're finally ready to start editing our code. We'll start by creating a boilerplate HTML page. This page will have an element with an id of app where we'll attach our React application. Additionally, we'll include a JavaScript app that lives in lib/app.js. This file doesn't exist currently but we'll take care of that shortly.

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Hello world example!</title>
  </head>
  <body>
    <div id="app"></div>
    <script type="module" src="/lib/app.js"></script>
  </body>
</html>

We'll add a .babelrc file where we'll add our Babel configuration

{
  "plugins": [["snowpack/assets/babel-plugin.js", {}]],
  "presets": ["@babel/preset-react"]
}

Next, we'll create a very basic React application in src/app.js

import React from "react"
import ReactDOM from "react-dom"

const App = () => <h1>Hello everyone!</h1>

ReactDOM.render(<App />, document.getElementById("app"))

We can run this application in watch mode with the following commands.

yarn babel src --out-dir lib --watch

This runs babel against our src directory and writes the transpiled files to a lib directory (what we reference in index.html)

yarn live-server

This command runs live-server to watch our HTML / JavaScript for changes. Generally, I would write a script or use something like concurrently that would run the two commands together as an npm script. For the sake of example, however, I like to focus on these items individually.

If we navigate to our browser and open the page (by default, localhost:8080) we should be greeted with the following:

Finally, we'll make some adjustments to our application to automatically run Snowpack when we include new dependencies. If we jump back to our package.json file, we're going to add a prepare script in the scripts object:

{
  "name": "snowpack-demo",
  ...
  "scripts": {
    "prepare": "npx snowpack",
    ...
  },

This prepare script will run in a couple specific instances, most notably for us, after we install a new dependency. Now if we include styled-components, we should see Snowpack running for us without any manual intervention.

yarn add styled-components
yarn add v1.21.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
...
success Saved 1 new dependency.
info Direct dependencies
└─ styled-components@5.0.0
info All dependencies
└─ styled-components@5.0.0
$ npx snowpack
✔ snowpack installed: react, react-dom, styled-components. [0.75s]
✨  Done in 3.73s.

Notice that Snowpack command that occured after yarn finished including the dependency. We can continue to Use styled components like we would outside of an application configured with Snowpack

Check out the demo application from this article here.

I'm very excited about the developer experience, and performance benefits that Snowpack could unlock. I'd love to hear about any of the strategies you're using to bundle your applications or of any thoughts you have on this article. Please find me on Twitter at @ryanlanciaux

An introduction to Styled-Components with React

Ryan Lanciaux — Thu, 09 Jan 2020 07:15:03 +0000

In this article, we are going to take a quick look at styled components, a styling library for use with React. While there are many ways to style React applications, styled components stands out as an excellent way style our applications as a series of components using familiar CSS syntax.

We will start by adding styled-components to our application through yarn or npm.

> yarn add styled-components

From our default React application, we’ll jump over to App.js and import styled from styled-components. We're ready to create our first styled component that we'll call Card by typing const card = styled.div - noting that our Card component will render as a div. We'll add a template literal directly after div and provide some CSS that defines a border, shadow, and padding — as well as a couple other properties. We should end up with something like this:

import styled from 'styled-components'
...
const Card = styled.div`
  border: 1px solid #ededed;
  box-shadow: 0 8px 6px -6px;
  padding: 16px;
  border-radius: 5px;
  background-color: #fafafa;
  margin: 20px 0px;
`

export default function App() {
  return (
    <div className="App">
      <Card>Hello!</Card>
    </div>
  )
}

Passing props to styled components

Now we can reuse this card component just like any other React component but what if we wanted to specify variations to this component? Maybe we want to have a version of the card that was highlighted a bit more.

Thankfully, since this is a component, we can pass props to it and interact with them in our styled definition through an interpolation. We’ll add a shouldHighlight prop to our App component specifying that shouldHighlight = true. After this, we'll add a string interpolation arrow function. This function will use props and will return either our default grey color or a highlight color.

const Card = styled.div`
  border: 1px solid ${props => (props.shouldHighlight ? "#F09" : "#EDEDED")};
  box-shadow: 0 8px 6px -6px;
  padding: 16px;
  border-radius: 5px;
  background-color: #fafafa;
  margin: 20px 0px;
`

export default function App() {
  return (
    <div className="App">
      <Card>Hello!</Card>

      <Card shouldHighlight>Highlighted Card</Card>
    </div>
  )
}

Themes

So far, we’ve been providing our colors, font-sizes etc, directly in our styled components. What if we had a Text component where we wanted to use the same highlight color? In our trivial example it would be relatively easy to duplicate the colors in each style definition. In a larger application, however, this could become a bit unwieldy to manage. This is where a theme is extremely useful.

A theme, is a javascript object where we can specify properties that we can use in our styled components. We could create a theme object that contains our colors.

const theme = {
  colors: {
    highlight: "#F09",
    grey: "#EDEDED",
  },
}

Once we have this theme object, we’ll place, we’ll want to utilize a ThemeProvider and pass our newly created theme to this provider as the theme prop.

export default function App() {
  return (
    <ThemeProvider theme={theme}>
      <div className="App">
        <Card>Hello!</Card>

        <Card shouldHighlight>Highlighted Card</Card>
        <Text>Some text</Text>
      </div>
    </ThemeProvider>
  );
}

Now any component that is rendered under this provider has access to our theme. We can update our components to utilize the theme prop:

const Card = styled.div`
  border: 1px solid
    ${props =>
      props.shouldHighlight
        ? props.theme.colors.highlight
        : props.theme.colors.grey};
  box-shadow: 0 8px 6px -6px;
  padding: 16px;
  border-radius: 5px;
  background-color: #fafafa;
  margin: 20px 0px;
`;

const Text = styled.span`
  color: ${props => props.theme.colors.highlight};
`;

I’ve found styled components to be an excellent way to style applications built with React (for teams that are on-board with a css-in-js based mindset). You can take a look at the finished example on CodeSandbox

I would love to know your thoughts or of any ways you’ve found useful to style your applications. Please let me know what you think on Twitter or the comments here.

Tailwind with React

Ryan Lanciaux — Thu, 02 Jan 2020 13:38:41 +0000

Tailwind is a CSS library in a similar space to things like Bootstrap or Bulma. Tailwind is different that instead of providing CSS for full components, it provides low-level utility classes. What this means is that instead of using class=“button” or “card” or something else, you’ll define your own button by composing Tailwind’s utility classes.

For an example of this, we’ll look at some HTML of a card created with Bootstrap and then a card created with Tailwind.

Bootstrap - See example on CodePen

<!-- from the Bootstrap documentation
     https://getbootstrap.com/docs/4.0/components/card/
-->
<div class="card" style="width: 18rem;">
  <img
    class="card-img-top"
    src="https://www.fillmurray.com/300/300"
    alt="Card image cap"
  />
  <div class="card-body">
    <h5 class="card-title">Card title</h5>
    <p class="card-text">
      Some quick example text to build on the card title and make up the bulk of
      the card's content.
    </p>
    <a href="#" class="btn btn-primary">Go somewhere</a>
  </div>
</div>

Tailwind - See example on CodePen

<div class="w-64 rounded overflow-hidden shadow-lg">
  <img
    class="w-full"
    src="https://www.fillmurray.com/300/300"
    alt="Bill Murray Placeholder"
  />
  <div class="px-6 py-4">
    <div class="font-bold text-xl mb-2">Card Title</div>
    <p class="text-gray-700 text-base">
      Some quick example text
    </p>
  </div>
  <div class="px-6 py-4">
    <button class="bg-blue-800 py-2 px-2 rounded text-white">
      Go Somewhere
    </button>
  </div>
</div>

You may have noticed that the Tailwind card has more verbose CSS class properties. However, we can now adjust how our component looks without changing CSS directly.

For example, if we wanted to give the card a background, we could apply a bg-color class to our opening div: <div class="w-64 rounded overflow-hidden shadow-lg bg-indigo-300">...</div>. The bg-indigo-300 class is one example of a Tailwind Utility Class.

With React

We’re going to start with a default Create React Project.

> npx create-react-app react-tailwind-example

Next, we'll add a couple dependencies

> yarn add tailwindcss tailwind.macro@next @emotion/core @emotion/styled

If you prefer styled-components, you could include that instead of @emotion/core @emotion/styled

Tailwind is the Tailwind library.
Tailwind.Macro is a Babel plugin macro for using babel-plugin-tailwind-components package without additional configuration. Please see kentcdodds/babel-plugin-macros if you're interested in learning more about Babel plugin macros.
@emotion/core | @emotion/styled - The css-in-js library we're using in this example.

We’re ready to start writing some example code that uses these libraries. We'll replace App.js with the following code:

import React from "react";
import styled from "@emotion/styled";
import tw from "tailwind.macro";

const Button = styled.button`
  ${tw`bg-gray-300 text-yellow-900 px-8 m-8 rounded h-20 text-3xl`}
`;

export default function() {
  return <Button>Testing</Button>;
}

Example output:

The styled component, Button, is using the Tailwind Macro tw to apply utility classes for things like a background color, rounded corners, font-size, etc. Combining Tailwind with Emotion or Styled-Components allows us to build flexible components quickly.

Using Tailwind CSS with my React applications has been extremely useful for me. I hope you find it helpful also.

Increase your productivity with Storybook's new Component Story Format

Ryan Lanciaux — Thu, 24 Oct 2019 21:08:56 +0000

Storybook is an incredible tool for building component based frontend applications. It helps you develop the parts of your application in isolation and apply some powerful plugins to ensure quality and consistency. With a recent release of Storybook, there is a new way that we can define our stories that can help us eliminate duplication in other areas of our codebase.

Component Story Format

Traditionally, Storybook stories look like the following code block:

import  React from 'react';
import { storiesOf } from '@storybook/react';

import Card from './Card';

storiesOf('Card', module).add('default', () => {
  return <Card>Something</Card>
});

These work well and this traditional format is not going away, however, there are some extra benefits we get by using the new component story format.

The new component story format looks like this:

export default { title: "activityFeed/ActivityFeedItem" };

export const standard = () => (
  <ActivityFeedItem
    name="Bill Murray"
    conferenceName="Some Conference"
    imageUrl="https://www.fillmurray.com/128/128"
  />
)

You may notice that the only Storybook specific item is the default export. The default export is a JavaScript object that takes a title that can be either the title of the story or the path to the story (this example is using a path) and some additional options.

The story definition is now a standard arrow function.

Benefits

One of the most immediate benefits that I've found when using the Component Story Format is testing. My tests can now reuse the stories.

I've traditionally had code in my tests that was very similar to the code in my stories for wiring up components (notice that the use of the ActivityFeedItem in this test is very similar to the story above):

import React from 'react';
import { render, getByText } from '@testing-library/react';
import ActivityFeed from './ActivityFeed';

it('has Bill Murray', () => {
  const { container } = render(
    <ActivityFeedItem
      name='Bill Murray'
      conferenceName='Some Conference'
      imageUrl='https://www.fillmurray.com/128/128'
    />
  );

  expect(getByText(container, 'Bill Murray is speaking at')).toBeDefined();
})

Using the new format, we can leverage the stories we have already created by importing them into our tests:

import React from 'react';
import { render, getByText } from '@testing-library/react';

// import our component from storybook 
// instead of re-wiring a new component for the test
import { standard } from './ActivityFeed.stories';

it('has Bill Murray', () => {
  const { container } = render(standard());

  expect(getByText(container, 'Bill Murray is speaking at')).toBeDefined();
})

This is especially helpful when you have a component that has multiple states. You can make a story that represents each of the various states and import these stories directly in your tests.

(Very contrived code - not real world scenario BUT should help show the concept):

// ActivityFeed.stories.js

export default { title: 'activityFeed/ActivityFeedItem' };

export const withBillMurray = () => (
  <ActivityFeedItem
    name='Bill Murray'
    conferenceName='Some Conference'
    imageUrl='https://www.fillmurray.com/128/128'
  />
)

export const withNicolasCage = () => (
  <ActivityFeedItem
    name='Nicolas Cage'
    conferenceName='Some Conference'
    imageUrl='https://www.placecage.com/128/128'
  />
)

// ActivityFeed.test.js
import { render, getByText } from '@testing-library/react';
import {  withBillMurray, withNicolasCage } from './ActivityFeed.stories';

it('has Bill Murray', () => {
  const { container } = render(withBillMurray());

  expect(getByText(container, 'Bill Murray is speaking at')).toBeDefined();
})

it('has Nicolas Cage', () => {
  const { container } = render(withNicolasCage());

  expect(getByText(container, 'Nicolas Cage is speaking at')).toBeDefined();
})

This technique also works with tools such as Cypress

I'd love to know your thoughts or of any other way that you're achieving better productivity in front-end development with similar strategies.

Quick tip: How to console.log in implicitly returned arrow functions

Ryan Lanciaux — Thu, 10 Oct 2019 19:28:06 +0000

Arrow functions with implicit returns are an awesome, concise way to interact with data.

An example of an arrow function with implicit return

const sum = (a, b) => a + b;

Where an arrow function without an implicit return would look like this:

const sum = (a, b) => { return a + b; }

Very similar but in the first example, the return value of the function is inferred where in the latter, we're specifying the return statement of the function.

Logging in a standard function / arrow function is pretty straight-forward

const sum = (a, b) => {
  console.log('HERE!');
  return a + b;
}

But how do we accomplish this same thing in an arrow function with implicit return? Many times, developers convert the function with implicit return to a standard function but this isn't necessary.

A potential solution

We can take advantage of the fact that console.log is evaluated as falsy. This means that if we ran

if(console.log('someStatement')) { 
  // ... 
} else {
 ...
}

We would encounter our else block every time. Using this knowledge, we can now update our arrow function with logging as follows:

const sum = (a, b) => console.log('A:', a, 'B:', b) || a + b;