@ryanditjia and @KyleAMathews we can continue the discussion here
Currently modules are imported with double quotation marks.
e.g.: import React from "React"
Should this be changed to single or backticks?
Our style rules are controlled by Prettier and Eslintrc — so you shouldn't worry about changing them — just run npm run format and they'll get set.
The rule we follow is use backticks for everything except for imports as they're not allowed there. This article explains why we prefer backticks https://ponyfoo.com/articles/template-literals-strictly-better-strings
@KyleAMathews,
Just trying out Gatsby for the first time. It sure weirded me out for a minute to see all those backticked strings.
Glad to know the explanation for it, but I'm not quite sure I agree with the article that there are zero negatives to "backticking all the things". Besides it being visually jarring (which I'm sure I'd get used to), I've spent the better part of my life typing double/single quotes. Using backtick all the time would surely take some getting used to. More importantly, I like knowing that, when I see a backticked string, there are probably variables to look for in there. Finally, I would say the multi-line advantages is diluted by the fact that the subsequent lines of the quote get indented, which may be unwanted, forcing you to run a cleanup function on it.
(Side note: I was surprised singles quotes beat double quotes 5:1. With React and JSX at least, I almost never put markup in quotes, which leaves apostrophes as the next most common thing to avoid having to escape. So, double quotes make more sense to me than single.)
Just to sort of follow up on what @devuxer said, I really don't understand this. Yes they make sense for string interpolation, and they are great for multiline strings, but how often do we actually write multiline strings outside of GraphQL queries, where we use them anyway to use the gql\`` syntax?
Personally I'm not even sold on the single quote, and the somewhat questionable decision to make the default something different from really every programming language that exists out there. But since that's a battle already lost, and we have prettier, we might as well stop caring about this issue, right? At least with prettier around we can be fine with using either single or double quotes as long as the project provides a config that auto-fixes the formatting.
But in this case, even prettier rejected backticks (https://github.com/prettier/prettier/issues/54). That would make one think that maybe this isn't such a great idea, especially if the alternative is to abuse a linter to fix formatting on projects that already use something else for formatting.
To be honest the blog post seems very unconvincing. We could cook up arguments for every single variant, and in this case the problems raised that backticks solve very rarely appear in real code (except for the graphql case), and thus enforcing them on the other 95% of strings, where it's sometimes even invalid, feels unreasonable.
“They are unique because they provide a lot of features that normal strings built with quotes do not, in particular: they offer a great syntax to define multiline strings.” I quote I found; the point is they are cleaner code syntax and very versatile. When I first started using them it was strange but now it’s the norm.
Most helpful comment
Just to sort of follow up on what @devuxer said, I really don't understand this. Yes they make sense for string interpolation, and they are great for multiline strings, but how often do we actually write multiline strings outside of GraphQL queries, where we use them anyway to use the
gql\`` syntax?Personally I'm not even sold on the single quote, and the somewhat questionable decision to make the default something different from really every programming language that exists out there. But since that's a battle already lost, and we have prettier, we might as well stop caring about this issue, right? At least with prettier around we can be fine with using either single or double quotes as long as the project provides a config that auto-fixes the formatting.
But in this case, even prettier rejected backticks (https://github.com/prettier/prettier/issues/54). That would make one think that maybe this isn't such a great idea, especially if the alternative is to abuse a linter to fix formatting on projects that already use something else for formatting.
To be honest the blog post seems very unconvincing. We could cook up arguments for every single variant, and in this case the problems raised that backticks solve very rarely appear in real code (except for the
graphqlcase), and thus enforcing them on the other 95% of strings, where it's sometimes even invalid, feels unreasonable.