v2.1.0

[Archmonger]

Changelog

• Change type hint on view_to_component callable to have request argument be optional.
• More DRY way of async view rendering.
• Have docs demonstrate how to use Django-IDOM with channels>=4.0.0.
• Concatenate some examples on the view_to_component docs
• Add note to docs about potential information exposure via view_to_component when using compatibility=True.
• Clean up docs on running tests

Checklist:

Please update this checklist as you complete each item:

• Tests have been included for all bug fixes or added functionality.
• The changelog.rst has been updated with any significant changes, if necessary.
• GitHub Issues which may be closed by this PR have been linked.

[Archmonger]

I need some support on the return type hint for view_to_component

Since the decorator is polymorphic, I can't figure out how to annotate how this decorator can be used with or without parenthesis.

The current annotations do not work properly when parenthesis are used, such as in our tests.

[rmorshea]

You'd handle that polymorphic behavior with @overload. Typing this correctly can tricky. Don't have time to give a full example now, but can help if needed.

[Archmonger]

Support on that would be great.

You can either commit it directly to this branch, or we can push this PR forward and PR proper type hints later.

[rmorshea]

Here's a sample of what the overload might look like:

@overload
def view_to_component(view: Callable | View) -> _ViewComponentConstructor: ...

@overload
def view_to_component(view: None = ..., other_params: Any) -> Callable[[Callable], _ViewComponentConstructor]: ...

# final definition
def view_to_component(view: Callable | View | None = None, other_params: Any) -> _ViewComponentConstructor | Callable[[Callable], _ViewComponentConstructor]: ...

[Archmonger]

Dang, overload is pretty neat.

I needed to do some modifications in order for the type hints to also work for use cases such as:

_view_to_component_kwargs = view_to_component(views.view_to_component_kwargs, compatibility=True)

I believe I got something pretty solid in terms of type hints. But I'm not sure why the github actions mypy has issues with it when my local mypy --show-error-codes src/django_idom does not.

[Archmonger]

@rmorshea not sure why my local MyPy doesn't generate warnings but GitHub actions does.

[rmorshea]

In general there seem to be a bunch of type: ignore comments that could potentially be resolved in a better way. Let's see if we can remove those. If not, could you comment with the reason?

For the ignore comments in our tests, I don't think those are necessary seeing as we don't actually type check our tests. If your IDE is showing type errors in those files, let's add an exclude pattern to our config.

[Archmonger]

I think it's worthwhile to keep the ignores in tests/*. Having mypy lint the tests helped in letting me detect when the @view_to_component decorator type hints were broken.

[rmorshea]

Perhaps we should run mypy on our tests then?

[Archmonger]

Done

[Archmonger]

Hopefully we can push this out today. I'd like to get the VTC security warning on the docs ASAP

[rmorshea]

I think we can merge this, but I'm a little uncertain whether running MyPy against our test suite is the right move. I'm worried that the benefits of doing so don't outweigh the burden it might places on potential contributors. MyPy allows for per-module configuration, so perhaps, in a follow-up PR, we could tweak our MyPy configuration for our tests to be more lenient than the configuration we apply to our tests.

[Archmonger]

I don't mind not running the test suite on the tests/ folder via workflows. But I'd like to be able to verbosely see errors when actually typing the tests.

Increasing test leniency might reduce the API/typehint bugs I manually catch while writing test.

[rmorshea]

MyPy is pretty configurable so I'm pretty sure we could strike a nice balance.