Shrine Rails Official Demo

[aipack...@gmail.com]

Hi,

Im learning shrine through Shrine Demo here. The demo use Uppy as recomended Javascript File Uploader Library. I'm cloning the demo and upload it to heroku.

When I'm trying to upload a 6 Mb image through uppy file input and submit the form, it seems it took long time for the request to complete. (The form freeze about 1-2 minutes depends on the file size, while the browser says "sending request to xxx.herokuapp.com..")
When I'm upload the same file through normal input, the request are much more faster. (see picture)
I notice that when uploading the file through uppy file input, in the request parameter it' also included the uploaded file.

I'm not changing the demo code, only using pg ( database on heroku ) and figaro gem.
How to set uppy file input with shrine to not include the uploaded file, so the request completed much faster?

[Janko Marohnić]

When I'm trying to upload a 6 Mb image through uppy file input and submit the form, it seems it took long time for the request to complete. (The form freeze about 1-2 minutes depends on the file size, while the browser says "sending request to xxx.herokuapp.com..")

What do you mean exactly by "form freezes"? If the UI is really frozen, then there is likely something computationally expensive going on in the JavaScript code itself. Do you get this same behaviour locally?

When I'm upload the same file through normal input, the request are much more faster. (see picture)

You mean when you're selecting files in the file input that accepts multiple files? It seems that for some reason you're getting a "302 Found" response for those requests, maybe that explains shorter requests? Are you using the latest master of the shrine-rails-example repo?

I notice that when uploading the file through uppy file input, in the request parameter it' also included the uploaded file.

You're saying that the form submit, i.e. the "POST /albums" request includes the actual files in the request body? That shouldn't happen, did you see any JavaScript errors. Can I access your Heroku app to inspect this further?

How to set uppy file input with shrine to not include the uploaded file, so the request completed much faster?

This is definitely not the intended behaviour. The whole point of asynchronous direct uploads is that the files themselves are not included in the form submit, only their JSON data.

Kind regards,

Janko

--
You received this message because you are subscribed to the Google Groups "Shrine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-shrine+unsubscribe@googlegroups.com.
To post to this group, send email to ruby-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-shrine/800976b1-d75e-48e4-a3b5-51b627c8d9a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[aipack...@gmail.com]

What do you mean exactly by "form freezes"? If the UI is really frozen, then there is likely something computationally expensive going on in the JavaScript code itself. Do you get this same behaviour locally?

after pressed the save button. it took long time before the page change. I'm guessing because maybe the app tries to include the file in form submit. because i can see the file in paramater tabs on web developer mozila (like jiberish text with random character and symbol) on the "POST/albums" request

You mean when you're selecting files in the file input that accepts multiple files?

Yes. on the file input that accept multiple file, the request are complete much faster, and there is no file uploaded in request.

It seems that for some reason you're getting a "302 Found" response for those requests, maybe that explains shorter requests?

I just realized that. i don't know what that's mean. but it seem the fie is uploaded correctly.

Are you using the latest master of the shrine-rails-example repo?

Yes. i download the zip from the github page yesterday. from the green button "clone or download"

You're saying that the form submit, i.e. the "POST /albums" request includes the actual files in the request body?

In my application look like it includes the actual files .  i can see the file in paramater tabs on web developer mozila ( jiberish text with random character and symbol).

That shouldn't happen, did you see any JavaScript errors. Can I access your Heroku app to inspect this further?

no problem. here is the address https://young-ocean-81185.herokuapp.com/

PS : Hi, sorry if i can't give the correct term on the problem and maybe cause confusion. :(  i'm new at rails not a software developer by profession. After read your blog, i think its important for me to understand how to implement shrine on my project correctly.

 

[Janko Marohnić]

Thanks for the info, I see the same problems when I try it out myself. However, I don't see these problems when I try out the example with my own bucket.

So, my only guess is that the delay in requests is due to network latency. This might be caused by the location difference between your computer and the Asia's S3 servers. I inspected the request timing breakdown on your Heroku app, and for me there was 1s of pure latency (DNS resolving and TCP connecting), before the file even began uploading. When I tried on my own app with Europe's S3 servers, and there was no latency.

I would recommend creating an S3 bucket that's closer to you. This doesn't look like a bug in Shrine for sure, because the latency is coming purely from the client side (browser). This is amplified by the fact that before every upload Uppy will send an additional OPTIONS request, due to something called "CORS".

I'm not experiencing the "302 Found" redirect response. There shouldn't be any difference in upload requests sent to S3 between the the two file inputs.

Kind regards,

Janko

--

You received this message because you are subscribed to the Google Groups "Shrine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-shrine+unsubscribe@googlegroups.com.
To post to this group, send email to ruby-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-shrine/d8defe10-3be4-427a-9302-1d21b1aa60cd%40googlegroups.com.

[Janko Marohnić]

I'm using ap-southeast-1 (Singapore) . Singapore is about 1 hour flight from here. its the closest bucket it can get :D

Ok, I guess we can rule that one out :) 

BTW, i'm still confused about file that get uploaded on form submit  (weird thing its happen when uploaded thru single file input only - picture attached). You said this is not intended behavior right? Just to make sure, you don't have this on your example right? 

I don't get this behaviour when I submit the form, it only includes the JSON data from uploaded files. If this is the behaviour you get, then for some reason the file input isn't getting cleared once the upload starts. Uppy internally does something like `fileInput.value = ""` to remove the selected file so that it doesn't get submitted.

I'm not sure what to tell you, I know it's not easy to debug stuff when you're new, but I'm simply not able to reproduce this (well, the slowness yes, but not the file being submitted with the form).

lastly, is there any chance CORS config could cause my problem?

I don't think so, CORS misconfiguration should typically result in the file being completely rejected.

On Sat, Apr 28, 2018 at 3:47 PM, <ha...@aipack.co.id> wrote:

I would recommend creating an S3 bucket that's closer to you.

I'm using ap-southeast-1 (Singapore) . Singapore is about 1 hour flight from here. its the closest bucket it can get :D

BTW, i'm still confused about file that get uploaded on form submit  (weird thing its happen when uploaded thru single file input only - picture attached). You said this is not intended behavior right? Just to make sure, you don't have this on your example right?



lastly, is there any chance CORS config could cause my problem?

--
You received this message because you are subscribed to the Google Groups "Shrine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-shrine+unsubscribe@googlegroups.com.
To post to this group, send email to ruby-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-shrine/e9c82708-64d1-42c9-9deb-61cdd3242e2a%40googlegroups.com.

[aipack...@gmail.com]

I don't get this behavior when I submit the form, it only includes the JSON data from uploaded files. If this is the behavior you get, then for some reason the file input isn't getting cleared once the upload starts. Uppy internally does something like `fileInput.value = ""` to remove the selected file so that it doesn't get submitted.

yes. you were right.  In my case, the value in new file-input that Uppy generated isn't getting cleared before form is submitted. Therefore it took a long time form to save, because the file is also being submitted with the form.

var uppy = new Uppy.Core({
      ...
      }
    })
    .use(Uppy.FileInput, {
      target:             fileInput.parentNode,
      allowMultipleFiles: fileInput.multiple,
    })
   ...

I have to manually clear the uppy file input value to avoid the file being submited during form submit. (I added it on uppy 'upload-success'  event)

uppy.on('upload-success', function (fileId, data) {

     // the upload-success event code is here
     ....   
    
    UppyFileInput = fileInput.nextElementSibling.firstChild  // *hacks: find the file-input that uppy use and clear it
    UppyFileInput.value = "";

  })

now the problem is gone.


PS: I'm curious if its there anyone else who clone/download this official example from git having the same issue. Or it just only me  -_-"

On Sunday, April 29, 2018 at 9:35:08 PM UTC+7, Janko Marohnić wrote:

I'm using ap-southeast-1 (Singapore) . Singapore is about 1 hour flight from here. its the closest bucket it can get :D

Ok, I guess we can rule that one out :) 

BTW, i'm still confused about file that get uploaded on form submit  (weird thing its happen when uploaded thru single file input only - picture attached). You said this is not intended behavior right? Just to make sure, you don't have this on your example right? 

I don't get this behaviour when I submit the form, it only includes the JSON data from uploaded files. If this is the behaviour you get, then for some reason the file input isn't getting cleared once the upload starts. Uppy internally does something like `fileInput.value = ""` to remove the selected file so that it doesn't get submitted.

I'm not sure what to tell you, I know it's not easy to debug stuff when you're new, but I'm simply not able to reproduce this (well, the slowness yes, but not the file being submitted with the form).

lastly, is there any chance CORS config could cause my problem?

I don't think so, CORS misconfiguration should typically result in the file being completely rejected.

On Sat, Apr 28, 2018 at 3:47 PM, <ha...@aipack.co.id> wrote:

I would recommend creating an S3 bucket that's closer to you.

I'm using ap-southeast-1 (Singapore) . Singapore is about 1 hour flight from here. its the closest bucket it can get :D

BTW, i'm still confused about file that get uploaded on form submit  (weird thing its happen when uploaded thru single file input only - picture attached). You said this is not intended behavior right? Just to make sure, you don't have this on your example right?



lastly, is there any chance CORS config could cause my problem?

--
You received this message because you are subscribed to the Google Groups "Shrine" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ruby-shrine...@googlegroups.com.

To post to this group, send email to ruby-...@googlegroups.com.

[Janko Marohnić]

Heh, I just started looking into your issue again 15 minutes ago, and was actually able to reproduce it now. For some reason the Safari inspector hides the file content from request data (so it appears the file is not submitted), but I was able to see that the file is begin submitted once I inspected request params. I was about to say what probably happened, but I see you already figured it out, congrats!

It's strange that nobody reported it before, thanks for being the first one. I'll correct the examples with your suggestion, and see if I can make a PR to Uppy to have the input field cleared by default.

Kind regards,

Janko

To unsubscribe from this group and stop receiving emails from it, send an email to ruby-shrine+unsubscribe@googlegroups.com.

To post to this group, send email to ruby-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-shrine/61954784-b43e-429d-ba96-8a03f82e1da6%40googlegroups.com.

[Janko Marohnić]

Ok, I updated the Rails example, and opened a ticket in the Uppy repo for adding an option to the FileInput plugin for automatically clearing the file input field.

[Aipack Studio]

Ahh.. Finaally. Thank you. First i found this issue when developing my own application which implement shrine demo's code, i thought I've messed up somewhere. Download the official demo and the problem persist. I've been pulling my hair since :D

It's strange that nobody reported it before...

Probably because on running application the issue are not much a problem, if user uploading small file  (like commonly use image) on a lightning fast upload internet connection. (which is not is my case ;p
Another wild guess, maybe just maybe.. more new shrine user are following other tutorials on internet -which doesnt use uppy- instead of official demo? so they don't have this problem? Putting link to rails shrine demo on shrine read-me git page will make the rails demo code easier to find :) so others can check on the code.

I still have few notes on Shrine Demo example.

• I'm still receiving 302 response on form submit instead of 200 OK. Both on my own app/ shrine example clone also locally an on heroku. But it doesn't interfere with software functionality. Everything work correctly, uploading, S3, save to database etc. since its' not impact anything,  i'm just gonna leave it as it it. - although i'm curious what causing the 302 response.
• If in the future Uppy are adding the option to automatically clearing the file input as we suggesting, (also it would be nice if uppy fileInput have feature to disabled selection of non allowed filetype on browse file window) that's mean the rails demo application will have to use newer uppy release.  Some of shrine official demo code might need to be change if we want to use newer uppy release. For example, right now  uppy is v.0.24.2, on this version, event like upload-succes is different.
  

uppy.on('upload-success', (file, resp, uploadURL) => { // ver 0.24.2


uppy.on('upload-success', function (fileId, data) {  // ver 0.22.0 on shrine demo rails app

using uppy v.0.24.2 on current shrine rails demo code will return JS error.

So, if we want to use newer Uppy version. Some code on Shrine demo rails will need to be change to accomodate uppy changes. 

That's all from me right now. Thank you for your feedback and the amazing gem.!

Cheers,

Harry

[Janko Marohnić]

Another wild guess, maybe just maybe.. more new shrine user are following other tutorials on internet -which doesnt use uppy- instead of official demo? so they don't have this problem?

Yeah, it's a shame that the GoRails screencasts were recorded at the time when jQuery-File-Upload was the only JS library I was able to utilize (I couldn't make Dropzone or FineUploader work).

Putting link to rails shrine demo on shrine read-me git page will make the rails demo code easier to find :) so others can check on the code.

Great idea, I just added the links to the demos on the top of the README (they are also linked in the "Direct Uploads" section).

I'm still receiving 302 response on form submit instead of 200 OK. Both on my own app/ shrine example clone also locally an on heroku. But it doesn't interfere with software functionality. Everything work correctly, uploading, S3, save to database etc. since its' not impact anything,  i'm just gonna leave it as it it. - although i'm curious what causing the 302 response.

Actually, this is expected/desired. After you submit the form and resources are saved, you then want to redirect the browser to a page which shows the created resources. That's the 302 response status, it tells browser to go to another page, and it's caused by the `redirect_to` call in your controller.

So, if we want to use newer Uppy version. Some code on Shrine demo rails will need to be change to accomodate uppy changes.

Yes, good catch, I plan to keep the demos up-to-date with the new Uppy releases. The reason why the demos are still using Uppy 0.22.0 is because version 0.23 changed how thumbnails are generated. By default images are resized to smaller dimensions, and those thumbnails get written to `file.preview`. However, that's async, so it's not guaranteed that `file.preview` will be present in the "upload-success" callback, and there is no "thumbnail callback" to listen to at the moment. In 0.22.0 you could disable image resizing by setting `thumbnailGeneration: false`, but in 0.23.0 thumbnail generation was extracted into the ThumbnailGenerator plugin (not yet documented), which doesn't have that option anymore, I opened a ticket for that.

Actually, maybe I could have the previews generated manually and just not use the ThumbnailGenerator plugin yet. I will give it a shot.

--
You received this message because you are subscribed to the Google Groups "Shrine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-shrine+unsubscribe@googlegroups.com.
To post to this group, send email to ruby-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-shrine/4ca53c74-777b-4d9c-8fea-38ca2d908400%40googlegroups.com.