Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Preview section #166

Closed
panz3r opened this issue May 13, 2020 · 23 comments · Fixed by #171
Closed

Improve Preview section #166

panz3r opened this issue May 13, 2020 · 23 comments · Fixed by #171
Assignees
Milestone

Comments

@panz3r
Copy link
Contributor

panz3r commented May 13, 2020

Feature Request

Describe the problem related to this feature request

Following the latest opened issues, I decided to open an "umbrella" issue to include all the feature requests, ideas and feedbacks related to the "Preview" section of material-ui-dropzone.

Describe the solution you'd like

The updated implementation will have to follow this requirements:

@max-carroll
Copy link
Contributor

max-carroll commented May 13, 2020

I would like to see better behaviour for when the file limit is one, for instance this would be if the user is uploading just one file (document, video, pdf, or image) in that case we would probably want the image to take up the entire width if the dropzone is small or perhaps centre if its large, will chip in with the development of this, sorry its just I haven't had any extra time this week. I think use cases for this would be when the dropzone is used as an Image Preview, or single file upload, I'm actually using it for both the use cases 😊

If I have a feeling I might have some time next week so may dedicate a day to dropzone dev 😊 which I absolutely love,

I may like to engage in discussions with any interested people during my development

@max-carroll
Copy link
Contributor

max-carroll commented May 14, 2020 via email

@max-carroll
Copy link
Contributor

as for with #145, #146 and #165 I make the following recommendations

  • investigate whether the overflow: hidden is causing a scroll bar in some situations and if it is fix by getting rid of the spacing issue, it seems to cause more problems that it solves, the developer can always pass in the spacing they want but it seems a bit mad to default to something that's going to look terrible on small devices and cause that rubber band issue in other times,

@max-carroll
Copy link
Contributor

  • SHOULD better follow Material Design guidelines

I have tried looking up the material design guidelines for drop zones, there doesn't appear to be any, can anyone find anything?

@panz3r
Copy link
Contributor Author

panz3r commented May 16, 2020

  • SHOULD better follow Material Design guidelines

I have tried looking up the material design guidelines for drop zones, there doesn't appear to be any, can anyone find anything?

Unfortunately there's no official design for a dropzone in the Material Design specs, possible approaches are the following:

@max-carroll
Copy link
Contributor

max-carroll commented May 18, 2020 via email

@panz3r
Copy link
Contributor Author

panz3r commented May 18, 2020

Yes I like the look of that behaviour, one more thing though,
Are we planning to move towards hooks and functional components?

I think that we should definitely move towards that goal (targeting a v4.x major version)

If so should we try to do that before we rewrite the preview list? Or do you think we should rewrite the preview list then rewrite everything in functional components and hooks?

For now I think that it's best if we try to only work inside the Preview component (which is already a functional one) and later adapt it if needed, of course we can use hooks on the master branch (since v3.x has a dependency which requires them), the only downside would be a not backportable solution to v2.x (which I suppose we'll sunset sooner rather than later).

@max-carroll
Copy link
Contributor

@panz3r , I've just started working on this

@max-carroll
Copy link
Contributor

image

Its position SHOULD be controllable by using a single prop previewType (instead of relying on a combination of showPreviews and showPreviewsInDropzone props, to be deprecated) - see #130

which props did we want to deprecate, I'm assuming previewChipProps and previewGridProps in favour of something which allows us to customise the things without a load of complicated props?

@panz3r
Copy link
Contributor Author

panz3r commented May 20, 2020

image

Its position SHOULD be controllable by using a single prop previewType (instead of relying on a combination of showPreviews and showPreviewsInDropzone props, to be deprecated) - see #130

which props did we want to deprecate, I'm assuming previewChipProps and previewGridProps in favour of something which allows us to customise the things without a load of complicated props?

The props to be deprecated are showPreviews and showPreviewsInDropzone, I'd replace them with something like previewType with values like none, inside (default) and below.

The 2 props you are referring to are used to customise the Mui components used inside the Preview section (maybe we can remove the previewGridProps one if we'll no longer have a Grid 😬 ).

@max-carroll
Copy link
Contributor

max-carroll commented May 20, 2020

It would appear that material-ui have an implementation of the image list https://material-ui.com/components/grid-list/ so I may utilize this, I'm just considering at the moment because one problem with this is there is only one size fits all prop of cols for how many columns the image will take up, and this means we would have to implement useMediaQuery to determine the screen size and then change this value depening on whether the screen is xs, sm , md, lg, xl, so it may be favourable to implement this ourselves. But then on the other hand its an out of the box soloution that supports the material design spec, so that may be worth it

@max-carroll
Copy link
Contributor

Hi there @panz3r, this is probably painfully obvious, but just a heads up in case, that this work is going to be a considerable rework of the PreviewList.js file and therefore would be extremely cautious about any parallel development on this file

@max-carroll
Copy link
Contributor

I'm halfway through experimenting at the moment, I've made a video of how I've got it behaving thus far if anyone wants to contribute feedback https://www.loom.com/share/1edf037829614f3fa4f77b7888fadf8b

@panz3r
Copy link
Contributor Author

panz3r commented May 20, 2020

@max-carroll Thanks a lot for sharing your progress, looks really good so far and I personally like it more than the current implementation .

Keep it up!! 👍 👍

@max-carroll
Copy link
Contributor

progress update 2 https://www.loom.com/share/55fd99ae1e404870a9eb08f2b7e906bd

I have ensured that we can customise it as much as possible, I've just got a few aesthetic issues to sort out

  • behaviour of the "Drop files here" message and icon when files are selected
  • styling of the remove button

Ill fix these and then send a PR, I might update the DropzoneArea.MD a little bit to fully showcase what we can do to customize the preview list

@panz3r panz3r modified the milestones: 3.2, 4.x May 21, 2020
@Thromind859
Copy link

It would be interesting to be able to actually open the files. Image previews are fine but how about other types of files? If I add a PDF file I can't open it. Would like to know if it would be possible to open it in a new tab, for example.

Currently, when I click on the files preview when they are inside the dropzone, it opens the file chooser. I have to right-click images and click 'open in new tab'. And that only works for images. If the preview is outside the dropzone, clicking on any file simply does nothing.

@jpainam
Copy link

jpainam commented Jun 18, 2020

any feedback or progress with this issue? the current version still has the same preview.

@max-carroll
Copy link
Contributor

This has been implemented however don't think this has been deployed to NPM yet, however if your super desperate (as I was) you can reference a link to the branch rather than using npm, by using this yarn add <git remote url>#<branch/commit/tag> so this would be yarn add https://github.com/Yuvaleros/material-ui-dropzone.git#v4.x the syntax is also similar if your using npm

@jpainam
Copy link

jpainam commented Jun 24, 2020

@max-carroll thanks, it worked. I have this warning

Warning: React does not recognize the `justifyContent` prop on a DOM element. If you intentionally want it to appear in the DOM as a custom attribute, spell it as lowercase `justifycontent` instead. If you accidentally passed it from a parent component, remove it from the DOM element.
    in div (created by ForwardRef(Grid))
    in ForwardRef(Grid) (created by WithStyles(ForwardRef(Grid)))
    in WithStyles(ForwardRef(Grid)) (created by Dropzone)
    in div (created by Dropzone)
    in Dropzone (created by DropzoneAreaBase)
    in DropzoneAreaBase (created by WithStyles(DropzoneAreaBase))
    in WithStyles(DropzoneAreaBase) (created by DropzoneArea)
    in DropzoneArea (at DropUploadImages.js:5)
    in DropUploadImages (at MyCompomentDropUpload.js:227)
"styled-system": "^5.1.5",

@max-carroll
Copy link
Contributor

Oh right yes, I'm having a look at the code now it appears that we are using justifyContent instead of simple justify on a Grid component, this shouldn't have any undesired effect on your page just an error in your console, we're basically just passing a component a prop it doesn't accept

@jpainam
Copy link

jpainam commented Jun 25, 2020

yes; you are right, I'm logging a lot of info in my console and wanted to get rid of any warnings. It doesn't affect my page though. i'll clone the v4 and fix it on my repo

@max-carroll
Copy link
Contributor

Ah awesome, could you create a pull request? 😉

@jpainam
Copy link

jpainam commented Jun 27, 2020

done!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants