I think that my imagining of the tool is sufficiently different to think that it isn't the same tool at all, and different workspaces wouldn't even be a thing. The composer UI in this case would provide a way to logically separate infra into different code bases but it would still have to know about all of them.
Edit: and actually, without a state there is no concept of a remote state. All codebases talk to the same "service" so circling a bunch of infrastructure and saving it to a specific git project would be easier than connecting to a bunch of remote states and reading specific resource days from them. Even if you're code repo doesn't declare a resource, the omniscient IAC service "knows all"
If you are using gmail, you probably could use "Check email from other accounts:" under "Settings / Accounts and Import". It fetches new mails periodically using POP3 or IMAP.
What I'm struggling with is consistency across pages, especially if you are not using a component framework.
I'll often end up with 50 similar, but different looking buttons.
On the other side when using a component framework, re-implementing all components when there are solutions already available (i.e. very similar in terms of look and feel Ant [1] or even Material-Ui [2]) sounds counter-productive.
Didn't you stumble upon such issue? How did you handle this?
If you're not using components (react/vue etc.) then you can use @apply - I think the secret with that is to blend inline tailwind and the applied style so you might say..
.button {
@apply rounded-md bg-gray-600 hover:bg-gray-300 text-white;
}
and then inline you might use class="button px-2 py-4" or similar to create specific styles. Of course these could be abstracted again to .big-button .small-button etc.
Tailwind has changed not only how I write CSS but how I think about writing front-end code completely - it's really great once it clicks.
How is it ad hoc? You're creating a class .button, but you're using the Tailwind-specified design system. This is how the framework is meant to be used!
Atomic/utility-first CSS doesn't mean that you shouldn't make classes. It just means that you should make them where they make sense. Don't make a new class just to add a margin to something,or whatever. If the margin is literally all this element needs, use the utility class directly. If it's the only place you'll use this combination of classes and naming the combination doesn't add anything, you might as well just keep it inline.
But if you find yourself repeating a bunch of utility classes, make a class with a semantic name once you start seeing the pattern. In some cases, like buttons, you might see that pattern before you've even started. That's fine. You should definitely have a button class (or three).
What you (probably) shouldn't have a is .info-page__navigation__aside__second_button that just includes the button class and adds a margin, or whatever... like we did at my old job. Urgh. I refer to this as "might as well be inline CSS" - making extremely specific classes that are only used once. If your CSS classes aren't reusable, all you gain from not having it inline is the joy of maintaining two text files, and manually look up the cross references. Tailwind solves this perfect, IME.
Not everything requires making a component. A CSS class can be fine, and I'd always use the least powerful way first. This is how the framework is meant to be used - that's the entire reason for having @apply.
I don't understand what you mean by ad hoc. It's a very structured approach. When utility classes don't work, you make a semantic class. If that doesn't work, you make a component. You can even use BEM naming if you want, you'll just be making a lot fewer classes.
They're all gone. Vanished completely from the website. And I was half-way through!!! Now they link to somebody's youtube channel for random Tailwind stuff rather than the nice walkthrough/tutorial that were the originals.
how does it get out of control? I've been using it for quite sometime now (with Vue). I really haven't experienced things getting out of control. Curious what problems you have had?
Shameless plug.
I made the ContainerTabsSidebar firefox addon[0], which is inspired by the TST. It groups tabs based on firefox privacy containers, which means every container has an isolated cookie store. I'm a tab hoarder and developed it to work for such "use-case".
It's very similar to the groups presented, but displays tabs vertically.
Very cool. I use Container Tabs so I can be logged into multiple AWS accounts simultaneously and this will be cool because they're sort of contexts. I wish I could see whole-desktop contexts but I'll settle for this.
Is there any other restriction/benefit in containers? I use the 'first party isolate' config option, and never really need e.g. different accounts logged in to same site, so as far as I'm aware there's no point?
I recently switched from an unmaintained tabs sidebar to 'Sidebery' which is quite nice in an 'overriding UI like it's made by Adobe' sort of way, which has got me using trees, and even tried containers (since unlike previous one it supports changing them and shows a coloured dot for which a tab is in) but I don't think it's gaining me anything.
With the first party isolate, mechanisms such as oAuth would not work. So the containers are less restrictive, but still allow you to have two sites with the same cookie context.
I've been using first party isolation for quite a while on desktop and Android and the only websites I experienced issues with are the Atlassian login and the Trello GitHub powerup.
Everything else, including tons of single sign in/OAuth websites, work without any issue.
Yep, ditto Atlassian. There's a big thread of people complaining about it on their forums too.
Unfortunately of course it'll always be a minority, and won't affect whether even those people (have to) use Jira or whatever, so not really any incentive for Atlassian to fix it.
Thank you for this - just what I needed! Tree-style tabs always seemed like a bunch of tabs thrown together with no organization, but your extension gives it the context that the user explicitly defined in the form of containers. I use multi-account containers a lot and this extension is just the supplement that was needed. Plus, being able to switch between container-tab view, bookmarks, and history is just the right thing to have.
I like this because it organizes my tabs in the same way I do mentally... however it doesn't actually reorder my tabs. What I mean is, Ctrl+Tab surfing through my tabs doesn't iterate the list as it is displayed sequentially.
I am planning to add automatic tab sorting to the plugin. There's a github issue for this exact problem. I just didn't have time to implement this feature. ;)
I'm probably missing something obvious, but I see in your review comments that I'm supposed to be able to add custom container names in the options... but I'm not finding them. Do I have to add through CSS?
It's not. But please make an issue on github[0] and if there's enough demand I will think about implementing this :)
Contributions are also welcome, though the codebase currently needs a bit of a refactor.
Tabs are bookmarks that can keep their state. Normal bookmarks have only the URL, and any parameters that go in the URL, but discard the rest, like your position on the page, your navigation history, or what you are doing in a PWA.
Tabs don't discard data, bookmarks do. Sometimes you just want the landing page and a bookmark is fine, other times you want the extra data and a long-lived tab is needed.
Tabs and bookmarks still feel pretty different. To update a tab, you activate the tab and then click links as usual. To update a bookmark, you activate the bookmark, click links, delete the old bookmark, create a new bookmark, and drag the new bookmark to the old one's location in the bookmark list (unless I've missed a shortcut here). Tabs feel very dynamic and are useful as a list or queue of work-in-progress, and bookmarks feel very static and are useful as a permanent list of important resources.
I'm pretty sure it's the same thing as Chrome's profiles functionality. I tried it out for a week, but it's not quite as robust as Firefox container tabs.
If you want to talk the email is in my profile.