Make this view helper.
def breadcrumb(&)
render(layout: 'common/breadcrumb', &)
end
<li class="breadcrumb-item">
<%= yield %>
</li>
<% if content_for?(:breadcrumbs) %>
<ol class="breadcrumbs">
<%= yield :breadcrumbs %>
</ol>
<% else %>
<% content_for :breadcrumbs do %>
<%= breadcrumb { link_to 'Foo', foo_url } %>
<%= breadcrumb { link_to 'Bar', bar_url } %>
<%= breadcrumb { 'you are here' } %>
<% end %>
module AssertBreadcrumbs
Crumb = Struct.new(:text, :href)
# Note: the block must have 1 argument per breadcrumb. It asserts their count.
def assert_breadcrumbs(&blk)
assert_select '.breadcrumb-item', blk.parameters.size do |items|
structs = items.map { |item|
if (link = item.css('a')[0])
Crumb.new(link.text, link['href'])
else
Crumb.new(item.text.strip)
end
}
yield(*structs)
end
end
end
assert_breadcrumbs do |item1, item2, item3|
assert_equal 'Foo', item1.text
assert_equal foo_url, item1.href
assert_equal 'Bar', item2.text
assert_equal bar_url, item2.href
assert_equal 'you are here', item3.text
assert_nil item3.href
endInlining it however, I'm with you.
Tailwind folks will tell you you’re holding it wrong, but every tailwind codebase I’ve seen winds up like this.
This person would write bad CSS, let's not put the blame on tailwind.
Also so much repetition instead of pulling each breadcrumb link out into a shared component. I understand it's just demo code for an article, but if all code bases end up like this that you've seen, the issue isn't tailwind.
Might just be me, but I'd rather just see clean(er) markup and styles in a css file.
But users of it will also never (unless they're doing something very weird) unintentionally break styling somewhere else while editing it later or have it broken by changes made elsewhere, have to come up with names for one-off element-specific styles, or have to jump between multiple files for their pseudo, colour scheme-specific and responsive styling.
Them's the breaks.
> have to come up with names for one-off element-specific styles
You never have to “name styles”. You have to identify the target element as different from other similar ones. There’s a subtle difference. I wonder if acknowledgement of that difference leads developers to pick different tools to help them manage their CSS.
> have to jump between multiple files for their pseudo, colour scheme-specific and responsive styling.
I’m gonna infer from this you’ve worked on large CSS codebases and know what you’re doing. I’m not trying to discourage you from whatever your doing: use Tailwind if it helps.
I’m just really interested in the problems and mental models that lead people towards Tailwind and similar tools. I’ve never felt drawn to them, despite also feeling the pain of sprawling CSS codebases. (I’ve worked on legacy CSS files so large that versions of IE stopped parsing them; I’ve refactored CSS repeated-but-not-quite across multiple teams’ reimplenetations of the main menu widget, etc).
What a refreshing thing to read compared to the usual language in web development-related topics on HN, where people are so often talking past each other, or just here to stick the boot into the topic in general.
The first thing which comes to mind is an app I worked on which had a sidebar which only a subset of users would see, and which was the only sidebar of its type in the entire app - if you were an insurance agent, it showed you the commission you would earn on the policy you were creating for your client, and how it was calculated. So a sidebar with a couple of different types of sections, headings, an itemised list and a total, some bold text here and there, and the app's "highlight" colour in a couple of places. A true one-off, not a framework for creating sidebars.
Structurally, that meant you had the sidebar container, sections and their contents, conceptually three-deep at worst (but deeper in terms of actual element nesting). This had been added to over time, as new requirements dictated, and I was tasked with adding a new, optional section at the end, depending on the type of policy. Exactly as you said, that requires that…
> You have to identify the target element as different from other similar ones
In this case, the original developer had started out using nested SCSS (so they didn't have to name anything, either! This was in an Angluar app, where styles are scoped to components) - styling was tightly-coupled to the structure of the particular markup which was used, which was probably easy to do given whatever the original requirements were. But as this was added to over time and by other developers, this file had grown into an hilarious nest of conditions. Make this text italic only if it's nested _here_ and directly follows a heading. Use flex justify-between for items nested here and here but _not_ here. Extra wrappers to shake off the existing styling. Patch-jobs to fix up what the existing CSS did to the new elements they needed to add.
This project wasn't even using Tailwind (and still isn't) and neither was I directly at the time, but I recognised that if you looked at the rat's nest of SCSS, _all_ it was doing was setting margins, paddings, colours and font styles, and that utility classes would be a much cleaner approach which wouldn't look any less ugly than what was already there. Tailwind had already done the work of naming things, so I added a new utility stylesheet to the app and copied some of its utilities into it, and recreated the sidebar in one file in one sitting with hot-reloaded styles, using the original as reference. I ended up deleting that SCSS file. That project is now using its own utility styles for one-off stuff like that and non-reused structural styling, regular old CSS for reusable styles for things which don't merit a component of their own, and the company's design system components.
I've seen similar results in free-range CSS codebases and ones using BEM-like or other conventions too, where people have had to invent "semantic" names when they need to do something different, rather than just "look, the designer's Figma says this section needs to have a different background colour and padding". And gods forbid if they tried to DRY up that CSS by moving styles which _happened_ to be common at the time up. It's always been multiple developers over a period of time, with changing requirements, mixed skillsets when it comes to web development, who just want to get shit done and move on. You _can_ hold it right with all of these ways of doing things, but if people are underthinking or undercaring about it, it doesn't tend to happen. Tailwind doesn't have a fix for that either, it just localises the blast radius somewhat.
This is my mental model for why I'm using Tailwind today in a React app, or any other component-based app framework or library: when I get requirements for a new chunk of UI I need to build, I'm immediately thinking about the state and the behaviour, I'm looking at what the designer has done in Figma, I'm mentally breaking down the layout into flexboxes and grids and spacing and our design system components in my mind, and I'm mentally mapping out the CSS for those. I create a new file, I sketch out the state and behaviour, I start creating the structure. I have the file open in my editor, the new component is hot-reloading in the browser. Tailwind is now the most route one way for me to translate what's in my head to the screen and get instant feedback. In the time it would have taken me to think of a name for a new CSS rule, add even just `display: flex;` to it and add the class name to the element, I've already typed `p-2 flex items-center gap-2` and started tweaking those spacings to match the design. Flip the app to dark mode. Tweak tweak tweak with some `dark:` classes and the design tokens we've added to our Tailwind config, all auto-completed nicely in the editor. Dark mode is done. Oh, what should this do on smaller screens? Reduce the size of the window. Tweak tweak tweak with some `md:`, `xs:`, whatever classes. Resize. Tweak. Resize. Tweak... Responsiveness is done. Now it needs to respond based on behaviour, let's `hover:` here and `focus:` this and `focus-within:` that and conditionally apply these properties here based on state. All in one file and one browser window for feedback. Nothing that can't be done perfectly fine in a regular stylesheet, but just so much less friction while implementing, in the same way that I'm also no longer thinking of identifiers to attach event handlers to and sticking code for those in a separate file.
I believe it's almost purely a developer experience thing. People want immediate feedback with hot reloading. They want to test out any little change right inline and get feedback without a mental context switch.
Check out this talk from Bret Victor called "Inventing on Principle" if you haven't yet : https://m.youtube.com/watch?v=NGYGl_xxfXA
It explores the benefits of this. Personally I don't often use tailwind but I do often use inline style attributes just to preview how something would look, before I refactor it into actual classes and rules.
Here are the big problems the Tailwind approach solves for me:
1. No debugging of cascade/inheritance bugs. Tailwind almost entirely discourages use of the cascade and eliminates and entire class of bugs, possibly the largest and most difficult class of bugs to deal with.
2. Less complexity in css files. Naming the differences between the styles is standardized, so there's less mental overhead to learn, you're not reinventing the wheel between projects or within a single project.
As a bonus that leads to: Less bloat in css files. There is going to be less in there because Tailwind already sets up essentially the minimum number of classes needed to get any visual effect. There's much less css code written by devs to search through, it'll have less entropy.
The big change in mental model when working with Tailwind is that the styling is done in the html, not in the css. This is good! You end up being able to determine where the styles are coming from just from the source code without diving into dev tools. You can tell, at a quick glance, why an element looks the way it does, and can easily figure out how to change it. Not only that, but you can be confident any changes will not have side-effects on other elements throughout random parts of the codebase. Removing or adding a class will only affect the element you want to change.
My only concern when I went down that route (besides the common criticism of how it's ugly) is how difficult it would be to do something like change the appearance of every instance of a certain type of button. I can only say I have not run into a problem with that. And even if I did it has not come up often at all, whereas the problems that approach solved has made development significantly easier.
lixtra•3mo ago
gls2ro•3mo ago
Here is what I like about this code:
1. It is explicit
2. Breadcrumbs are information that this action needs to set. You can set them in the views or in the controller via these helpers. But no matter where you put the data it is custom data that you as developer set and it is specific to this controller.
The information about how to navigate from homepage to this show method is something that either: you can use meta-programming to try to get it if you would for example scope controllers based on paths (not sure it is a good idea) or you have to provided as Rails cannot know if your controllers/views are in the top namespace.