DEV Community

Cover image for Better frontend development with inspiration from the culinary world
Ryan Lanciaux
Ryan Lanciaux

Posted on • Edited on

Better frontend development with inspiration from the culinary world

Temporary Update


Book giveaway must Retweet by Midnight on 12/05/2020 (GMT -5)


Cover photo by Fabrizio Magoni on Unsplash

Software development, as an industry, has a constant struggle with shipping quality code. While many developers have metrics for what quality means, there's a challenge in ensuring these metrics are met, especially as a codebase grows over time.

We build our computer systems the way we build our cities: over time, without a plan, and on top of ruins.

- Ellen Ullman

Mise en place

While software development is a relatively young field, there are more established industries that we can learn from to help us write better code. For generations, chefs tout a mise en place mindset as a technique that is critical to success in the kitchen.

The system that makes kitchens go is called mise-en-place

The Salt, NPR

Or stated a different way

Mise en place refers to all of these various components that are prepared ahead of time and you have in place for that moment when you get the order and you put the dish together.

Adam Savage, Every Tool's a Hammer

Mise en place is the organization and mindset that goes into preparing a meal. It's something that may seem like more work ahead of time but can help ensure productivity, consistency, and quality.

What does this have to do with building our frontend applications?

Many frontend technologies have the concept of components. Components are building blocks of our frontend applications but can be overlooked as a tool for ensuring productivity, consistency, and quality. Often times we see focus on the screens that a user of our application sees and overlook the building blocks of these screens. If care and attention to detail are not exercised, it's easy to end up with a series of one-off and duplicate components in a codebase.

Brad Frost has an excellent book called Atomic Design about building great design systems. In this book, (and related article) he defines a design system (or component library) as a series of levels. In this methodology, base level components are atoms, atoms compose into molecules, which compose into organisms and so on (I highly recommend Brad's post / book to really see this mindset in action). While I generally do not use the same terminology, I appreciate the concept of base level components and compound components for building reusable front-end applications.

You may notice that some of these concepts apply to the mise en place mindset we're discussing. We can build our components before creating a single screen / page in our application.

How can we apply a mise en place philosophy to our codebase?

If you're on board with this mindset, you may find it helpful to work on components in isolation, outside of the standard placement in an application. At the most simple level, we could create test pages for each component. This can introduce some challenges ensuring that the pages don't get deployed, that other developers know where to find them and other things of this nature.

Thankfully, there are many tools for working with components in isolation. Storybook is the one I use most.

Using Storybook, we can add "stories" for each of our components. A story is a function that defines what should be rendered as well as ways to interact with the inputs and outputs of the components we are developing (these are generally through Storybook addons). Imagine we are building a component library that has base components like Button, Text, Card, etc. and a series of more complex compositions of these components. We would develop these lower level components entirely in Storybook and only later hook them up with actual data in our application.

Storybook helps speed up the process of creating component libraries by allowing us to run our components outside of our standard application. For example, yarn storybook could be configured to start Storybook, where yarn start could be configured to run the development version of the application.

Storybook default screen

Very basic storybook window

This separation between where we develop components vs. where we build our application can be very helpful when applying a mise en place mindset. We can see Storybook as the workspace we are preparing and the application screens as the dish that is composed of the various ingredients we prepared in advance.

How does this actually help me?

In the culinary world, a chef can make many dishes out of a small number of ingredients expertly prepared. Ingredients are composed to make components of a dish and these components are turned into full meals. This allows chefs to quickly build many dishes of similar quality and consistency.

Lets use the "fast casual" restaurant Chipotle as an example. There are a series of meal components prepared in advance and ready to be composed into a meal. Imagine how long it would take to create if every time a customer placed an order, the people preparing the meal needed to cook and prep every part of the meal. Outside of the time it would take, this would open up the process to more variation which may result in lower quality.

This has a parallel in software development as well. If we build components that are tested and meet the quality standards we desire, we can build screens that give us a higher degree of confidence in the result in less time.

Lets imagine that we need to build two screens for an application. Product Listing and Product Detail. We want related products on product detail to look exactly like the product list.

Product listing

Product Listing

Product detail

Product Detail View

We could build a list item component that would be (pseudocode/JSX-like) like the following:

// ListItem output - JSX like but pseudo code
<Card>
  <Flex flexDirection="row">
    <ProductImage src={imageSrc} />
    <Flex flexDirection="column">
      <Heading>{headingText}</Heading>
      <Text>{description}</Text>
    </Flex>
    <Button onClick={onClick}>Click this</Button>
  </Flex>
</Card>
Enter fullscreen mode Exit fullscreen mode

Once we have this in place, we can reuse this in both ProductList and ProductDetail.

<ListItem headingText="Some Item" description="This is the description ..." ... />

You'll notice that while this ListItem is a resuable component, it consists of other reusable components. Flex / Heading / Button, etc could all be lower level components (While this is pseudocode, the usage of Flex is basically a Rebass Flex component).

Wrapping up

While there are thousands of opinions on great ways to develop applications, I've found that applying a mise en place philosophy increases quality, consistency, and ultimately productivity while building frontend applications.

I think if we just became a little bit more organized, used a little bit more mise-en-place, understood what we really need and only do what we really need, I think we'll have more time

  • Dwayne Lipuma Culinary Institue of America

(this is cross-posted from ryanlanciaux.com)

Top comments (11)

Collapse
 
caweltjr profile image
John Cawelti

Thank you my friend for identifying this concept! I have been coding for 40 years. Lately, looking for new gigs, I have tried to explain to potential employers this very concept, but I didn't have the right words. Now, I do! Why do you want an experienced developer? The mise en place from years of experience!! This will make answering interview questions so much easier! Thanks again!

Collapse
 
_rice_salad profile image
Rhys S

A fresh perspective on good programmer habits, really enjoyed the read. It's a more difficult thing to visualise, but personally I can see this applying to backend development too. Focusing on small components that do one job, and do it well, is setting yourself for reusability.

Collapse
 
eenewbsauce profile image
Ryan Tracey

Right on! I've been trying to bring this idea to life for a while. Looks like you beat me to it! One thing I'd add is the use of tooling to build the components in the same way. Say for instance Plop.js as a way to scaffold components.

This way all component code would have a similar look and feel. Tests would be similar, etc. To use your culinary analogy, component scaffolding is like a cookie cutter. It ensures everything starts from the same mould. You can add sprinkles and whatnot later, but the origin is the same and repeatable!

Collapse
 
ryanlanciaux profile image
Ryan Lanciaux

Very cool! I'd love to hear your take on this analogy too.

I really appreciate the thought of scaffolding things and will have to check out plop a bit more sometime. Similar wavelength here too on automating things and will be a topic for a future post BUT I also use scaffolding hand-in-hand with these techniques 😀 These are from a talk I'm giving on this overarching topic:

Automation Slides

I am currently using Gluegun to make a configurable CLI I'm using on some of my projects, Blastoff. I'm hoping to write more on this a little later on.

Collapse
 
patimen profile image
John Long

I used this same analogy while trying to explain why functional programming concepts can improve backend code. I think the analogy goes even deeper into our day to day coding practices.
In much backend code, you are taking various data and combining it and reshaping it into other forms. Much conventional code is a real mess in creating these. Either a really long method with a bunch of for loops and mutable objects or a lot of helper functions that represent extra risk and maintenance, and we haphazardly assemble our objects.
Functional programming allows us to greatly improve and simplify this process, so that our assembly of an object looks straightforward and all of our processing gets done either in advance or with pre-built methods we assemble together (like Chipotle), such as map, filter, reduce, etc.
I’m working on a blog article describing this in more detail, but thanks for the extra insight and verbiage!

Collapse
 
ryanlanciaux profile image
Ryan Lanciaux

Very cool - looking forward to your article!

Collapse
 
xenoarchitect profile image
Rasheed Ali

Go blue

Collapse
 
shellscape profile image
Andrew Powell

Go Blue

Collapse
 
integerman profile image
Matt Eland

Looking forward to hearing your talk on this later today. I listened to the audiobook of Every Tool's a Hammer and it was the first time I've encountered this concept by name.

Collapse
 
ryanlanciaux profile image
Ryan Lanciaux

Awesome - it should be fun.

I was reading that book around the same time I was preparing the talk that this post is a derivative of. I wasn't expecting "mise en place" to be a topic at all but was pleased to see it and how it relates to making things :)

Collapse
 
integerman profile image
Matt Eland

I think you and I have similar thinking patterns on certain things. I've called my patterns "component thinking" and thinking about software as a series of isolated components.

I'd encourage you to write more about Blazor in particular.

Once again, enjoyed the talk and meeting you. I purchased 3 books while listening to you speak.