Emotion

We are in the process of adopting Next.js as our React framework and using Storybook to help build our React components in isolation. This new part of our frontend is written in TypeScript, and we use Emotion for CSS/styling. For delivering data, we use GraphQL and Apollo. Jest, Percy, and Cypress are used for testing.

We use React because it is the best framework to work quickly, cleanly and with good results. The composition paradigms of React are far superior to most other frameworks and allow for creating a smart and logical component tree, that is high performant.

Also it can be used to create great UI in combination with ES6, TypeScript, GraphQL and Emotion, if used right. The ecosystem definitely gives solutions to nearly all problems. And I can only recommend using Gatsby, if you need Server-Side-Rendering!

Last week I started a little side project that helps me and my family share recipes. The result is Julienne and I've open sourced it for anyone that's interested. In brief, the stack:

1. @{React}|tool:1020| on the front-end + liberal use of hooks.
2. @{Firebase}|tool:116| to handle authentication and database persistence. Firebase makes bootstrapping your app so much easier. Auth, especially when combined with react hooks and context, is really powerful.
3. Firebase functions and @{Algolia}|tool:589| to provide full-text search of the recipes.
4. Sancho-UI (my own design system) for developing the responsive user interface, and react-spring for providing animations.
5. @{Emotion}|tool:8770| for handling css because I really love using the css prop to style my elements.

I hope the source code can be helpful to some, and would absolutely love contributions!

For Stack Decisions I needed to add Markdown in the decision composer to give our users access to some general styling when writing their decisions. We used React & GraphQL on the #Frontend and Ruby & GraphQL on the backend.

Instead of using Showdown or another tool, We decided to parse the Markdown on the backend so we had more control over what we wanted to render in Markdown because we didn't want to enable all Markdown options, we also wanted to limit any malicious code or images to be embedded into the decisions and Markdown was a fairly large to import into our component so it was going to add a lot of kilobytes that we didn't need.

We also needed to style how the markdown looked, we are currently using Glamorous so I used that but we are planning to update this to Emotion at some stage as it has a fairly easy upgrade path rather than switching over to styled-components or one of the other #cssInJs alternatives.

Also we used React-Mentions for tagging tools and topics in the decisions. Typing @ will let you tag a tool, and typing # will allow you to tag a topic.

The Markdown options that we chose to support are tags: a, code, u, b, em, pre, ul, ol, li.

If there are anymore tags you'd love to see added in the composer leave me a comment below and we will look into adding them.

#StackDecisionsLaunch

When we rebooted our front-end stack earlier this year, we wanted to have a consolidated and friendly developer experience. Up to that point we were using Sass and BEM. There was a mix of HAML views, React components and Angular. Since our ongoing development was going to be exclusively in React, we wanted to shift to an inline styling library so the "wall of classnames" could be eliminated. The ever-shifting landscape of inline CSS libraries for React is sometimes difficult to navigate.

We decided to go with Glamorous for a few reasons:

1. Previous team experience with this library
2. We can write our styles in plain @{JavaScript}|tool:1209| (which brings many benefits)
3. It supports server-side rendering
4. It has great composition patterns

As you may or may not know, Glamorous has ceased active development and been mostly superseded by Emotion. We are planning to migrate to either Emotion or @styled-components in the near future, and I'll write another Stack Decision when we get there!

#inlinecss