django_components.component_registry.AlreadyRegistered error when using component as view. about django-components HOT 6 CLOSED

Yes, this is on Master. When I get home I’ll try and get you a PR with a failing test case. Probably what I should have done first before blasting you with a wall of text.

from django-components.

OK, I think I've found the root cause. The class hash function here:

Take for example, a Todo component with a .py file under components/todo/todo.py. When using the regular @component.register("todo") wrapper, the return value of cls.__module__ is todo.

However, if you import the module in another file, such as urls.py like this:

from components.todo.todo import TodoComponent

urlpatterns = [...]

the return value of cls.__module__ will be components.todo.todo.

This is an issue because the documentation at

from calendar import Calendar

However this import will not work if the urls.py module is in a directory above the calendar folder. You need to write it like this:

from components.calendar.calendar import Calendar

or use a relative import. Either way, the hash function will not match because the module will not simply be calendar.

The only way to get this to work is if where you are importing the module (such as in a urls.py) is in the same module as where the component is defined. And indeed, in the sample/test project that the component views tests use:
https://github.com/EmilStenstrom/django-components/blob/91b4accfebf74f3f7a8cf2ecab03789a1979d578/sampleproject/components/urls.py

the urls.py file is in the same folder as greeting.py where the component is actually defined. So in this case, the hash function will match - but this does not match what the documentation says to do.

So I think there are two options:

1. Update the documentation to say that the urls.py file needs to be in the same directory as the module that defines the component, or
2. Make the hash function a bit more robust so that it stands up to imports from different paths.

EDIT:

I did some looking into this and I believe the root of this stems from the auto-detect and import that happens on init here:

No matter what I try, I cannot get the identity of the modules imported via autodetect to match the identity of classes imported later, such as in a urls.py. The full module path does not match. This makes it hard to make the class_hash method work.

As an example of this, I can make my project work by getting the component directly from the registry, thus circumventing the second attempt to register:

from django_components.component_registry import registry
urlpatterns = [path("components/todo", registry.get("todo").as_view(), name="todo")]

But this seems a little hacky.

Another option would be to make the class_hash method a little less resrictive:

    def class_hash(cls):
        return hash(cls.__name__)

This will still prevent someone from the (probably most common case) of trying to register a second component under the same component name, unless the class name they use also matches, but at some point you gotta just stop it 🤷‍♂️

from django-components.

Hi @Fingel! Before going further into troubleshooting this: Are you sure you're using the latest version of the code? I JUST released 0.34 to pypi. Which version are you using? Does things work when you run the latest release?

from django-components.

@dylanjcastillo Is on it.

It was me who suggested this (faulty) change in the PR review, going with Dylan's original suggestions would have avoided this! :)

from django-components.

@Fingel, I got the PR for this now. Please give it a try, and let us know if it works!

@EmilStenstrom, no worries. I should've included a specific test for this, and we have that now!

from django-components.

Yes! It works now. Nice work. The python import system is so funky.

from django-components.