File Uploader (beta)

[amureki]

Brief description of the feature and motivation behind it

Greetings dear Uploadcare fellows. I am trying out your product, and it indeed seems like a fantastic tool for my product needs. I see there is a new "File Uploader (beta)" JS widget that is looking quite promising. So, I wonder, what are the plans for this Python library? Is there a plan to switch to that version at some point?

Currently, I see it is pinned to the old widget with outdated version 3.7.4.

This question comes because I am using Python/Django stack, and it would be quite neat to be able to use this package with fully working integration instead of doing APIs via client myself.

I'd also be happy to contribute to that work in case it is a desired way of going, and Uploadcare will be the final choice of mine.

Cheers, Rust

[dmitry-mukhin]

Rust,

thanks for the question. You can easily use the new version if you just change the link to any version.

And we'll change the shipped version when the Uploader is out of beta.

[amureki]

Rust,

thanks for the question. You can easily use the new version if you just change the link to any version.

And we'll change the shipped version when the Uploader is out of beta.

Thanks for the blazing reply! That means, there is no breaking changes affecting APIs, and it should just work out of the box? I'll try this out.

[dmitry-mukhin]

There are breaking changes. If you use custom JS or HTML attributes to control behaviour, things may break. Tread lightly.

[evgkirov]

The new widget is quite a big departure from what we've had previously, some changes are needed here.

Here are my thoughts on how it could be done.

Settings

New setting:

• legacy_widget (defaults to False). This setting would affect on how FileField and ImageField are rendered. If set to True, the project will use the older jQuery-based widget.

Different behavior of some of existing settings when legacy_widget is on/off:

• widget_version defaults to 3.x for the legacy widget; defaults to 0.25.1 for the new widget.
• widget_build defaults to full.min for the legacy widget; defaults to regular for the new widget (minimal, regular and inline are available options). For the new widget it will also change the rendered component name (may be introduce a different name for this setting?)

Form fields

Depending on legacy_widget setting form fields will render differently.

If set to False it would be something like this:

<lr-config
  ctx-name="uploader_arbitrary_file"
  pubkey="demopublickey"
></lr-config>

<lr-file-uploader-minimal
  ctx-name="uploader_arbitrary_file"
  css-src="https://cdn.jsdelivr.net/npm/@uploadcare/blocks@0.25.1/web/lr-file-uploader-minimal.min.css"
  use-input
></lr-file-uploader-minimal>

<lr-data-output
  ctx-name="uploader_arbitrary_file"
  use-input
  input-name="arbitrary_file"
></lr-data-output>

If set to True:

<input type="hidden" name="arbitrary_file" role="uploadcare-uploader" data-public-key="demopublickey" data-integration="Django/3.2.19; PyUploadcare-Django/4.1.0" data-clearable="" id="id_arbitrary_file">

Additional concerns

Should we allow for more advanced configuration of widgets?

Something like this in settings:

UPLOADCARE = {
    ...,
    "widget_config": {
        "use-cloud-image-editor": True,
        "source-list"="local, url, camera, dropbox",
    }
}

Those could be overridden within a form field:

ololo = FileField(..., widget_config="...")

Or through a model field — in the same manner — but that's debatable (I personally don't think that it is a good idea).

Should be possible via widget's attrs.