Emil Stenström

> 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. Since providers likely...

I really like the idea of **component packages**! I can see a future when someone bundles django-components for a whole front-end library as a django app, that you can simply...

> I'm also torn about the 'auto' feature. I know the pain of reasoning about code that's too magical (and, yes, the 'auto' design would rely on a fair bit...

About namespaces: I still think relying on providers to pick names that don't crash with anyone else is putting a lot of responsibility on them. Especially when they should also...

Would this be an option? ```python from django_components import component @component.register("calendar") class Calendar(component.Component): template_name = "template.html" class Media: css = "style.css" js = "index.js" ``` That is: We automatically look...

**About relative paths**: The idea for an algorithm was: Check if the path has no slashes, if so resolve against the current directory. If not found fall back to the...

Well explained. What I didn't like is now different components might have an uppercase name, and some a lowercase one. No template tags use uppercase ever in Django, so it's...

It's worth considering two perspectives here: 1. What does the default, recommended, component look like? 2. Which parts is possible to customize when you want something that's different from the...

Quick replies to @lemontheme: * I personally like your `template.html - style.css - index.js` structure more than what we recommend right now. Agreed on the pros and cons. The strongest...

@timothyis You can modify how a specific component is rendered by overriding [Component.get_js_dependencies](https://github.com/EmilStenstrom/django-components/blob/master/django_components/component.py#L94) method on a component. Go wild! :)