Resolve django_form limitations #270

Current Situation and Proposed Actions

Serializable data fields do not work (Unresolved)

The following fields are currently incompatible with django_form due to ReactPy's client and server not supporting file serialization:

• FileField
• ImageField

My two initial ideas on how to solve this:

1. Extend the current implementation but use a custom messaging schema
   • Specifically, adding some sort of messaging websocket schema that can differentiate between layout messages and file transfers.
   • On the server-side, we could consider re-using Django's UploadHandler.
   • The UploadHandler will probably need to be subclassed to get things working with ReactPy.
2. Determine how to pipe the HTTP client/server stack through a websocket
   • This would be convenient - specifically would enable us to retain the exact same upload behavior that users would expect on any specific Django version

It might be difficult to figure out what to do on early websocket termination. It might also make sense to create a throttling system where the server can control the incoming upload speed.

There was a related draft PR for file uploads that could be leveraged for inspiration.

Multiple choice fields do not work (Fixed in #298)

There is an additional set of fields that are currently incompatible with django_form, and this seems to be caused by weirdness with how Django re-hydrates/re-renders the form submission data:

• SplitDateTimeField
• MultiValueField

When the form data is submitted, those fields don't properly rehydrate themselves when given form submission data. This causes incorrect re-renders.

This might just be a limitation of our current rendering methodology. If that is true, then fixing this will require digging into Django's form rendering stack and figuring out why they don't rehydrate properly when given the expected values.

Form restoration on page load (Unresolved)

The following limitation will also need to be resolved:

• Implement form restoration on page reload.
  • Perhaps pre-rendering plus the browser's default behavior may already handle form restoration well enough? Probably not, but this should be investigated.
  • Maybe this involves creating a new setting called form_restoration_method that can be set to "URL", "CLIENT_LOCAL_STORAGE", "SERVER_SESSION", or None. Note that "URL" mode would likely limit the user to one form per page.
  • Maybe we need to mandate the user provides a key for the form if using form restoration in order to properly re-hydrate the form? Or perhaps we can use the form's CSRF token as the key? Or perhaps it can be linked directly to the browser's scope["session"]? This needs some additional thought.