Add react-dropzone

[boton]

• Before making a proposal, have you used the issue search functionality?

What is your proposal?

Add react-dropzone library to the portal.
Repo: https://github.com/react-dropzone/react-dropzone
Docs: https://react-dropzone.js.org

We try to plan a new uploader and remove the AUI old one, maybe this helps.

Why would adopting this proposal be beneficial?

This component adds the logic of d&d files.

• No UI, based on hooks
• validation on Drag
• validation on Drop

What are the alternatives to this proposal?

Making our own component.

[julien]

Hey @boton

As you might know we already have react-dnd in liferay-portal.

If I'm not mistaken the Page Editor (echo) team already has a dropzone component and I'm sure they'd be very happy helping you out.

[julien]

/cc @victorg1991 @p2kmgcl @sandrodw3 @veroglez

[victorg1991]

Hey @julien
Our dropzone shares the name with this, but it is a totally different thing. it seems that react-dropzone takes care of a bunch of things related to files being dropped, our dropzone is only related to fragments

[wincent]

We should probably include a link to bundlephobia on issues like these to help us get a feel for the size of the dependency graph.

[julien]

@victorg1991 yes I know, but I still think it could be used as an example instead of adding yet another dependency

[bryceosterhaus]

I mentioned this as potential idea for Clay as well. Perhaps the lexicon team would want to establish a common pattern for this and we could provide a clay component built with react-dnd.

[boton]

What do you think @emiliano-cicero @jbalsas @drakonux @victorvalle?

[drakonux]

Hey guys! I'm a bit lost. All the dropzones in Portal should follow the tips of Drag and Drop pattern (but Portal Designers can differ from the definition made) :

• https://liferay.design/lexicon/patterns/drag-and-drop/

About files. Lexicon has a design specifically for Portal for File Uploader made by @emiliano-cicero :

• https://liferay.design/lexicon/satellite-components/file-upload/

@bryceosterhaus we want! we always want more consistency in Portal. Sadly, we can't proactively decide if this is important. So @boton keep in mind what implications have if a Product Team requests help from the infra-team (design or front).

Said this:

• Lexicon Team can create a new definition for file dropzones in Portal (create a LEXI ticket).
• Lexicon as a design language could adopt it if it makes sense to have it for more products.
• Create a ticket with your expectations, priority, deadlines and all the information needed.

I encourage you and your team @boton to send a complete proposal and Lexicon will review it.

[wincent]

Just to mirror here some offline discussion I had with @ambrinchaudhary about this, here are my 2 cents:

• We need to be expedient/pragmatic about enabling teams to deliver features on a reasonable timescale. That means a balanced approach, avoiding the two extremes:
  • At one extreme, we risk delaying the delivery of value while we engage in a lengthy search for The Ultimate Library™ 🦄 , validate it, or implement our own in Clay, and ship it in a central/shared location.
  • At the other extreme, we risk chaos and entropy by allowing a slew of inadequately vetted dependencies into liferay-portal that increase bloat, increase our exposure to potential security vulnerabilities, wind up being a maintenance headache etc.
• In terms of evaluating react-dropzone itself:
  • Pros: bundle size impact (5.3k gzipped) seems likely to be justified given the complexity of the task involved (handling cross-browser issues etc). Project is widely used (6.7k stars, 798k weekly downloads).
  • Mixed: Maintenance may not be super active (last commit was in November 2019; and see call for maintainers on issue tracker); this may be a good thing (less churn) or a bad thing (if project dies).
  • Concerns: a couple of IE issues on their tracker ([IE] - cannot drag and drop folder with files in IE 11 react-dropzone/react-dropzone#926, [IE-11] - should't open modal twice react-dropzone/react-dropzone#928).
• Overall, it seems reasonable to at least trial react-dropzone in a controlled fashion: ie. install it as an isolated dependency in the Lima team's project so that they can get unblocked and move forward, and we can gather real world experience with it and decide whether it is generalizable enough — and reliable enough — to warrant being moved into a central location. This may end up being technical debt (if we end up having to migrate away from it), but it seems like a reasonable trade-off, and preferable to creating something from scratch in a vacuum divorced from real usage. This is similar to what we did with react-dnd, which we basically tested in isolation in the segments-web project, before deciding that it was "good enough" to become our standard bundled drag-and-drop offering in frontend-js-react-web — in hindsight, that worked out ok: the library isn't perfect and updating has proven to be painful, but on the balance it has still provided quite a bit of value at a reasonable cost.

[bryceosterhaus]

@wincent I was thinking about something similar over the weekend specifically in relation to Clay. One approach that I think we can add to help avoid the two extremes would be to have the Clay team actively create demos and examples that people need. For example, I am thinking this would mean that someone creates a GH issue on clay like "How to add a dropzone" and then we can publish a new demo storybook with our suggested implementation.Or we can also respond with codesandbox example as well if that is easier. This issue gave me this idea since it is likely better for us to show an example implementation of how we would hypothetically add it to Clay, without having to commit to publishing it quite yet. This should up speed up delivery and also give teams some autonomy.

Long term the goal would be to see patterns that other teams need and then for the Clay team to implement commonly used components. This ultimately helps us reduce chaos because we know how people are implementing features and should be easier for us to swap out in the future.

If the component is very time sensitive, we can push them to create their own implementation that we can go back and adjust later. Obviously this leans more to the "chaos" side, but I think it should be rare that something is truly that urgent.