Advanced Websocket Features

[Archmonger]

New Features

• Automatic WS reconnection (settings.py:IDOM_WS_RECONNECT_TIMEOUT)
• Propogate WS down to components
• Support authenticated components (Login the user and save the session if auth middleware is detected)
• Pin "idom-client-react": "^0.33.3"
• Update tests to add websocket as a component parameter
• Update tests to use render shortcut instead of HttpResponse
• Change ALLOWED_HOSTS = ["*"] in tests to allow LAN access
• Rename IdomAsyncWebSocketConsumer -> IdomAsyncWebsocketConsumer
• Readme clean up. fixes, and updates

[Archmonger]

if I don't complete this PR by Thursday, I likely won't be available to pick it back up until October 4th.

[Archmonger]

Reconnecting WS has been developed.

Currently works on client side disconnect.

There are some caveats...

1. Reconnect is not graceful.
   • All IDOM modules are effectively "reset" to the first rendered state upon reconnect.
   • All variable values are lost.
   • We may need to implement a database model to store the component state in relation to a Websocket session.
     • Perhaps this should be a new decorator, such as @persistent_component
2. Reconnections after server restart is broken due to Django IDOM design.
   • We only add modules to IDOM_REGISTERED_COMPONENTS upon template first render, so all components are completely unknown after server restart ("Unknown IDOM view ID").
   • We will need to develop a feature to resolve this. I'll get to it eventually.
3. As you mentioned before the alert in IDOM core is annoying and needs to be removed.
   • See Remove Reconnecting WS alert reactpy#513

[Archmonger]

If approved, the last limb of Conreq blocking factors is react-router support.

Unfortunately I'm too much of a ReactJS scrub to PR that into IDOM Core, so I'll need your support on that.

---

Side note

Before we actually start getting repos with django-idom dependencies, I believe we should change IdomAsyncWebSocketConsumer to have a lowercase socket to fall in line with Django conventions (ex AsyncJsonWebsocketConsumer).

What are your thoughts?

[Archmonger]

Let me know what additional changes are needed in this PR.

[rmorshea]

Been really busy lately. Will try to get to this next week.

[Archmonger]

I updated the PR description.

Let me know if you need me to split this PR into separate parts to be more easily digestible.

[rmorshea]

LGTM - just minor nits.

Once I implement the use_context hook I think we'll be able to get rid of this websocket parameter and just allow the user to access the socket from anywhere:

@component
def MyComponent():
    socket = use_context(WebSocketContext)
    ...

With everything else that needs to happen that's probably a ways off though so this should be fine for the time being.

[Archmonger]

Side note...

We should also consider adding pre-commit.ci to all idom-team repos. I see that IDOM Core is using it currently, but it's using a fairly minimal config.

You can just take my extensive pre-commit.ci configuration file and add it in.

[Archmonger]

All comments have been resolved.

[rmorshea]

I see that IDOM Core is using [pre-commit] currently, but it's using a fairly minimal config.

From my experience, pre-commit has been most helpful in resolving issues that can be fixed automatically (e.g. black, sorting imports) which is why I've kept it fairly minimal. Linters like flake8 and pylint that just report errors can be annoying if you want to introduce a commit that represents intermediate progress. So including pre-commit hooks that automatically add EOF new lines and strip out trailing white space would be great to have.

A longer-term solution to this would be to make an idom-team/python-package-template repo that pre-bakes all the standards we want to enforce.

[Archmonger]

A longer-term solution to this would be to make an idom-team/python-package-template repo that pre-bakes all the standards we want to enforce.

I recommend using the repo-file-sync GitHub action to automate standardized configurations across idom-team repos.

That's what we use at Jazzband alongside our template repository.