adriaan

Glad you're on board! So, approaches (1) through (3) work on the assumption that the onus is on the _provider_ of the app to get it right, not its _consumer_....

Thanks for chiming in. Keep the ideas coming! Appreciate you sharing ideas from other frameworks/ecosystems. Your example sort of reminds me of something I've been working on. It's still very...

> What stops them from picking the same namespace accidentally. That's the neat part. Nothing. Which sounds terrible until you realize that that's how all installed apps work. AppConfig's *name*...

> [...] a future when someone bundles django-components for a whole front-end library as a django app, that you can simply pip install and add to INSTALLED_APPS to get access...

I get what you're saying. It's something I really like about the few JS frameworks I've studied. But I'm just not sure how well such an approach would be received...

Thanks for all the feedback, guys! I have a good feeling we're going to be able to converge on a design that's both ergonomic and sensible. @VojtechPetru, I see what...

Returning to the discussion about 'component packages', I think you've touched on a really good heuristic for evaluating design decisions. Related is the 'zero hours of sleep' test, which is...

I think we need to be careful about resolving paths relative to the component sub-directory _by default_. I'd personally advise against it. First, it breaks with Django convention, which assumes...

Alright, we're at about 50% agreement. I call that progress. =p (Although, we've gone slightly off-topic wrt the OP, since we still need figure out how we feel about implicit/explicit...

(Yes, please do!) So, regarding the **component names**, there's one other approach I can see working that would both make things more explicit and give an indication of the recommended...