FileField: show image thumbnails [WiP]

[wmertens]

Make filefields look like this if they are an image:

Still to do:

• proper styling, instead of the inline flex. How should I do this?
• allow disabling thumbnails, how about with plain: true?

[mxstbr]

How about using the same styling/component the CloudinaryImage field uses?

[wmertens]

Sounds good, but that code seems a bit involved. Could you outline the changes needed?

[mxstbr]

No idea, I didn't write it 😀 you'll have to dig in!

[JedWatson]

👍 good feature, @wmertens

IMO this should be opt-in, because unlike images from cloudinary which we can dynamically resize, general images may be really large (i.e multiple megabytes) which I don't think we should be blindly foisting on users by default.

How about thumbnail: true as the field option to turn this on?

Also, it might be worth looking at something like sharp for thumbnail processing in Keystone. There's also a neat image-resizer project that's sort of like a DIY cloudinary, but it's nontrivial in size and to implement so I don't want to bundle it with Keystone by default.

Then again, we're getting into Image field territory here.

[adnasa]

Wait. why are you sending an object containing url when only url is interesting to the FileThumb component?

[wmertens]

@adnasa This is just React, it's exactly the same as saying <FileThumb url={url}/> and gets transpiled to the exact same React.createElement call.

[mxstbr]

Might be worth changing that to <FileThumb url={url} /> – I wasn't 100% sure what that did either.

[wmertens]

I'm hoping that JSX will allow writing <FileThumb {url}/>, see facebook/jsx#23

Would that have been less confusing? If so, some upvotes would be nice :)

[adnasa]

since it is a single prop

<Component singleProp={value} />

is much more readable than

<Component {...{ singleProp } />

[SharadKumar]

This middleware might help replace most of Cloudinary stuff and work well with S3!
https://www.npmjs.com/package/image-steam

Sharad

On 31 Aug 2016, at 5:27 PM, Jed Watson <[email protected]mailto:[email protected]> wrote:

? good feature, @wmertenshttps://github.com/wmertens

IMO this should be opt-in, because unlike images from cloudinary which we can dynamically resize, general images may be really large (i.e multiple megabytes) which I don't think we should be blindly foisting on users by default.

How about thumbnail: true as the field option to turn this on?

Also, it might be worth looking at something like sharphttps://github.com/lovell/sharp for thumbnail processing in Keystone. There's also a neat image-resizerhttps://github.com/jimmynicol/image-resizer project that's sort of like a DIY cloudinary, but it's nontrivial in size and to implement so I don't want to bundle it with Keystone by default.

Then again, we're getting into Image field territory here.

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/keystonejs/keystone/pull/3397#issuecomment-243681167, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFO-EMMvW1vJlngGYP8pOUr7qwrRMlWBks5qlSzagaJpZM4Jr5LR.

[wmertens]

@SharadKumar I think that in order to implement this properly we will need asilvas/node-image-steam#39 but I haven't thought it all through yet.

[bassjacob]

Hi @wmertens, thanks for the work on this PR so far. The scope of this seems to have blown out a little bit in the comments, but I think it does need to be styled to get merged. Are you still interested in getting this in?

[wmertens]

Yes, interested, but 0 time right now…

…

On Thu, Dec 22, 2016, 4:18 AM Jacob Bass ***@***.***> wrote: Hi @wmertens <https://github.com/wmertens>, thanks for the work on this PR so far. The scope of this seems to have blown out a little bit in the comments, but I think it does need to be styled to get merged. Are you still interested in getting this in? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <keystonejs/keystone#3397 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADWlnvHHmOn8LWK0U1W3XhP6xTbA3tAks5rKewLgaJpZM4Jr5LR> .

[htor]

This should really be merged...

[JedWatson]

@htor we'd love to have this feature but it needs proper styling before it can be merged, and a way for developers to opt in to it (or at least more thought around the logic that enables it). There are a number of scenarios where blindly rendering a preview of a file based on the file type could be bad UX; key being files can be quite large images, so on mobile or a slow connection simply navigating to the item details screen could kick off a huge download (e.g. original photos)

[outluch]

Come on, it is so essential feature to show local images in admin UI...

[wmertens]

@outlunch feel free to implement this then :-D

[outluch]

@wmertens, Already, but I'm not familiar with github pullrequests, etc. Maybe someone could make it correct way?
Here is my bad pull-request:
keystonejs/keystone#4198

[htor]

@wmertens
this can now be closed as image thumbnails are now implemented in keystonejs/keystone#4509

[Pyav123]

@htor , I am using [email protected] but it is not showing image thumbnail using the local storage, I am using
image:{
type: Types.File,
storage: newStorage,
thumb: true
}
Can someone please tell what else I have to do? I need this feature.

[htor]

@Pyav123
at the moment you need to depend on the git version of keystone (don't think npm is updated yet), so put this in your package.json and run npm install:

"keystone": "https://github.com/keystonejs/keystone.git"

then see what happens.

[Pyav123]

Hello @htor I saw your suggestion on https://stackoverflow.com/questions/40879375/keystonejs-4-0-file-system-storage-adapter-image-preview but this is also not working for me, I am getting the code implemented for this inside keystone but unable to see the preview. Please suggest on this.

[Pyav123]

Hey @htor it is working now , forgot to mention url: true inside the schema , just thumb: true didn't work for me , Thanks!!