What is styled-components?
Who uses styled-components?
Why developers like styled-components?
Here are some stack decisions, common use cases and reviews by companies and developers who chose styled-components in their tech stack.
I was building a personal project that I needed to store items in a real time database. I am more comfortable with my Frontend skills than my backend so I didn't want to spend time building out anything in Ruby or Go.
I stumbled on Firebase by #Google, and it was really all I needed. It had realtime data, an area for storing file uploads and best of all for the amount of data I needed it was free!
I built out my application using tools I was familiar with, React for the framework, Redux.js to manage my state across components, and styled-components for the styling.
Now as this was a project I was just working on in my free time for fun I didn't really want to pay for hosting. I did some research and I found Netlify. I had actually seen them at #ReactRally the year before and deployed a Gatsby site to Netlify already.
Netlify was very easy to setup and link to my GitHub account you select a repo and pretty much with very little configuration you have a live site that will deploy every time you push to master.
With the selection of these tools I was able to build out my application, connect it to a realtime database, and deploy to a live environment all with $0 spent.
If you're looking to build out a small app I suggest giving these tools a go as you can get your idea out into the real world for absolutely no cost.
The capability of style customization is one a large deal breaker for frontend SDKs. To solve this, we decided to use styled-components in our SDK, which makes it easy to add support for themes on top of our existing components. This practice reduces the maintenance effort for stylings of custom components and keeps the overall codebase clean.
I just finished a web app meant for a business that offers training programs for certain professional courses. I chose this stack to test out my skills in graphql and react. I used Node.js , GraphQL , MySQL for the #Backend utilizing Prisma as a database interface for MySQL to provide CRUD APIs and graphql-yoga as a server. For the #frontend I chose React, styled-components for styling, Next.js for routing and SSR and Apollo for data management. I really liked the outcome and I will definitely use this stack in future projects.
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:
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.
ReactQL is written in TypeScript to provide full types/Intellisense, and pick up hard-to-diagnose goofs that might later show up at runtime. React makes heavy use of Webpack 4 to handle transforming your code to an optimised client-side bundle, and in throws back just enough code needed for the initial render, while seamlessly handling
import statements asynchronously as needed, making the payload your user downloads ultimately much smaller than trying to do it by hand.
React Helmet was chosen to handle
<head> content, because it works universally, making it easy to throw back the correct
<title> and other tags on the initial render, as well as inject new tags for subsequent client-side views.
<style> tags when using #StyledComponents.
React Router handles routing, because it works both on the server and in the client. ReactQL customises it further by capturing non-200 responses on the server, redirecting or throwing back custom 404 pages as needed.
Koa is the web server that handles all incoming HTTP requests, because it's fast (TTFB < 5ms, even after fully rendering React), and its natively #async, making it easy to async/await inside routes and middleware.
We use Sass because I invented it! No, that's not a joke at all! Well, let me explain. So, we used Sass before I started at Rent the Runway because it's the de-facto industry standard for pre-compiled and pre-processed CSS. We do also use PostCSS for stuff like vendor prefixing and various transformations, but Sass (specifically SCSS) is the main developer-focused language for describing our styling. Some internal apps use styled-components and @Aphrodite, but our main website is allllll Sassy. Oh, but the non-joking part is the inventing part. /shrug