Allow for a customizable fallback mapper

[nanuxbe]

Hello,

I'm not sure whether you're accepting pull requests or not. If you're not, feel free to close!

My thinking here is to be able to set a fallback_mapper in the settings that defaults to dj_angles.mappers.django.map_include.

What one would be able to able to accomplish by switching the fallback mapper is to use their favorite component library as fallback instead of {% include %}.

So for example, assuming django bird, with the appropriate mapper:
<dj-partial /> would be mapped to {% bird partial %}{% endbird %} instead of {% include 'partial.html' %}

I'm opening this as draft, as if that's something you'd be interested in, documentation would be needed

[adamghill]

This feature makes sense to me. 👍 I'm not sure about the setting name, though. I wonder if something like "component_fallback_mapper", "component_mapper", or "default_component_mapper" would be more clear? What do you think?

To merge in I'd add docs to settings.md and a test, but I can handle both of those things if you want.

Warning, tangent ahead: The use of import_string makes me wonder if that would be useful for the mappers dictionary as well. Currently, the value is either a string or a callable, so this would make it more complicated -- there would be two types of strings, i.e. a Django templatetag or an import string? I guess I could differentiate between the two types of strings by looking for a period, but that feels a little hacky. The other approach is to deprecate the current mappers approach and move everything to be import strings and make that work -- would reduce some if string, else if callable logic I have floating around. But, would require updates by anyone using custom mappers (admittedly, I have no clue how widespread that is). Mostly thinking out loud here, but let me know if you have any thoughts!

[nanuxbe]

This feature makes sense to me. 👍 I'm not sure about the setting name, though. I wonder if something like "component_fallback_mapper", "component_mapper", or "default_component_mapper" would be more clear? What do you think?

I think I like "default_component_mapper" best... it's also the longest though

To merge in I'd add docs to settings.md and a test, but I can handle both of those things if you want.

I'll take a look at how you write your tests, I haven't touched pytest in ages...
Also I tried running ruff but it spat quite a lot of warnings, so I'm not sure if I'm doing something wrong here.

Re: tangent
to stay backwards compatible I see 2 possibilities:

1. use a format like 'tag:dotted.path.to.templatetag' and try import_string only on strings that start with tag:
2. always try to import, catch the ImportError and fallback to the legacy behavior

What do you think?

I'll change the settings name and get started on the docs

[adamghill]

I think I like "default_component_mapper" best... it's also the longest though

Let's go with that! I'd rather be explicit than terse. :)

Also I tried running ruff

just lint should be good. Let me know what errors you see.

always try to import, catch the ImportError and fallback to the legacy behavior

This is a good idea!

[nanuxbe]

It should start looking somewhat ok. But....

1. I'm not convinced by having dj_angles.mappers.angles.map_include_when_no_tag
2. For some reason tests are flaky on my machine (ie: they pass every odd time I run them -> something to do with settings override) I'm assuming it's a "me problem"

Let me know what errors you see.

src/dj_angles/mappers/angles.py:5:30: F401 `minestrone.Element` imported but unused
  |
3 | from django.template import engines
4 | from django.template.exceptions import TemplateDoesNotExist
5 | from minestrone import HTML, Element
  |                              ^^^^^^^ F401
6 | 
7 | from dj_angles.mappers.include import get_include_template_file, map_include
  |
  = help: Remove unused import: `minestrone.Element`

src/dj_angles/mappers/thirdparty.py:1:1: I001 [*] Import block is un-sorted or un-formatted
  |
1 | / from collections.abc import Callable
2 | | import logging
3 | | from typing import TYPE_CHECKING
4 | | 
5 | | from dj_angles.mappers.utils import get_attribute_value_or_first_key
6 | | 
7 | | if TYPE_CHECKING:
  | |_^ I001
8 |       from dj_angles.tags import Tag
  |
  = help: Organize imports

src/dj_angles/tags.py:1:1: I001 [*] Import block is un-sorted or un-formatted
   |
 1 | / from typing import TYPE_CHECKING, Optional
 2 | | 
 3 | | from minestrone import Element
 4 | | 
 5 | | from django.utils.module_loading import import_string
 6 | | 
 7 | | from dj_angles.attributes import Attributes
 8 | | from dj_angles.mappers.angles import map_angles_include
 9 | | from dj_angles.settings import get_setting
10 | | 
11 | | if TYPE_CHECKING:
   | |_^ I001
12 |       from collections import deque
   |
   = help: Organize imports

Found 3 errors.
[*] 2 fixable with the `--fix` option.

[adamghill]

The imported but unused error on src/dj_angles/mappers/angles.py:5:30 should now be fixed in main. The others are interesting. I wonder if you have a different version of ruff than I do?

[nanuxbe]

ruff 0.7.0

[nanuxbe]

I've rebased on main and I'll ignore the 2 ruff errors for now

[adamghill]

@all-contributors please add @nanuxbe for code, tests, and docs

[allcontributors]

@adamghill

I've put up a pull request to add @nanuxbe! 🎉