Michael Brevard

> `computed` is being passed a simple value here, so it will be released as soon as your component is released, so no tricks :) I apologize for.the comically late...

> My solution was to just do a custom validation I also opted for a custom validation with a simple computed property. As it turns out, sometimes using the frameworks...

~~So the current issue is, some tests fail, seems to be at random. The vast majority of successful tests indicate the feature is working, as tested with the .server/.client pair...

I was thinking of changing up the way visibility based component behaves, to ensure we don't pollute the DOM unnecessarily with extra nodes. What do you think? Do note I...

First things first, thank you so much for the feedback! ## TL;DR The functionality itself is possible, even right now, just with a few type issues. The exporting, the loader...

Documentation updates to include the new `loader` prop and the corresponding utilities following harlan's reviews will be added soon. I'll mark it as draft for the time being until I...

> being able to create the components explicitly I can definitely see this being useful in advanced use cases. Though I do sense some slight issues with it. Functionality wise...

To summarize: All components and their loaders are fully functional now, including overriden triggers, with corresponding tests. They are all auto imported (loaders and components), and they have added type...

I will add another type of delayed hydration for general purpose conditionals. For never-hydrated components I don't quite know if it's worth making a wrapper over just using a .server...

Looks like there was some regression, the tests in dev fail now despite passing previously