Use new dropzone/input component in limel-file

[civing]

Makes use of the new limel-file-dropzone and limel-file-input component in limel-file. All the other functionality of limel-file should be unchanged.

Fixes https://github.com/Lundalogik/crm-feature/issues/3941

Review:

• Commits are atomic
• Commits have the correct type for the changes made
• Commits with breaking changes are marked as such

Browsers tested:

(Check any that applies, it's ok to leave boxes unchecked if testing something didn't seem relevant.)

Windows:

• Chrome
• Edge
• Firefox

Linux:

• Chrome
• Firefox

macOS:

• Chrome
• Firefox
• Safari

Mobile:

• Chrome on Android
• iOS

[github-actions]

Documentation has been published to https://lundalogik.github.io/lime-elements/versions/PR-2820/

[LawrenceBorst]

Almost ready. I'll add fixups for some of the comments and you can decide if you want to keep them 😛

Requested changes no longer applies

[civing]

Is this expected behaviour? If we have the file-input component disabled that means that any click wont open the native file select dialog but will still propagate the click event.

As it was previously any click event were stopped, so if you had something like this the chip would not open a link

<limel-file-input disabled={true}>
  <limel-chip text="cat.jpg", link={href: "/cat.jpg"} />
</limel-file-input>

[adrianschmidt]

I would say that expected behaviour for this PR is that the component keeps working as it did before… isn't this supposed to just be a refactor?

[civing]

Yeah, the implications discussed are in <limel-file-input>. Or what do you mean?

[adrianschmidt]

Ah, ok, I didn't notice that this wasn't limel-file 😄

I'm not sure, since I haven't yet gathered enough context, but since this component is meant to wrap some other component, I think the consumer needs to be responsible for controlling the behaviour of the wrapped component. So if they don't want anything to be clickable inside limel-file-input when limel-file-input is disabled, they have to disable the component inside it themselves. If we block all clicks, we make it impossible for the consumer to implement at more nuanced behaviour, like being able to click on existing chips, but not add new files, for example.

[adrianschmidt]

Sum up of discussion we had in a huddle:

We'll pause this refactoring for now, because we don't use limel-file in the activities composer, so we don't need this refactoring right now. Then we will look into possibly changing the UI a bit. We would like there to be a simple button for browsing files to upload, rather than the currently quite weird interaction where you focus a text-field to get the file-dialog. With keyboard navigation, you currently have to tab to the input field, and then press enter to get the file-dialog. That doesn't seem very intuitive, and is probably really bad for accessibility…

[civing]

In one iteration of this PR I wrapped the <limel-chip-set> inside a <limel-file-input> only if we expected it to be clickable (no file selected). I changed it into this but just now realised we need this change a85e952 to make it work.

It's maybe a bit strange to have it like this if we would like to make the component work with multiple files? Maybe that's a headache for another time ... ?

This comment is also relevant in this context https://github.com/Lundalogik/lime-elements/pull/2820/files#r1521124280

[LawrenceBorst]

Maybe that's a headache for another time ... ?

Yes, for another time :)

[LawrenceBorst]

Tested this last night. Everything works as expected. Code looks good, had some comments but they don't really concern the changes here :)

[civing]

I've been thinking a lot about the chipset that serves as both clickable chips but also as a file input handler. I would like to move the file input handling to a new button and let the chipset be a chipset and nothing else.

[lime-opensource]

🎉 This PR is included in version 37.11.4 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀