Client needs demand that we don't use the default SLDS style for the file uploads.

Basically, have a specific icon we have to use for uploads which isn't the SF one.

In prior releases, we were able to do this because the label for="" value of our custom component for adding attachments. The first time lightning:fileUpload was instantiated the value was "input-1" every time. We could use that to open the file upload when someone clicked on our label.

The newest release has modified the way this works, and it seems to be the case that the input-X value changes each time. So, we're trying to figure out a way to open the upload ui without knowing or predicting what the X value will be.

Thanks to Locker, we don't have a great way to interrogate the DOM to determine what the right value should be.

One horrible hack we've tried is just increment through 1-10 and trying to invoke click() on the label element after each increment. However, this doesn't work in the javascript - only in the console. I've tried both component.find("").getElement() and document.getElementById(""); edit: it doesn't work because the click() function appears to do nothing. If I do the same using console, it works great.

Any ideas about whether this is even feasible? Is there another approach worth investigating for this?

It would be great if lightning:fileUpload had a public method we could call to just open it, but I'm sure there are reasons.

1 Answer 1


A roadblock like this typically means that you need to write your own component. Further, I would say that the lightning namespace components are meant to build "real" Salesforce interfaces, the way a real salesforce.com-employed developer would add a new feature to the standard interface (hint: many of these elements are in the standard interface, go look at the source DOM some time if you're curious). If they don't have a particular feature, it probably means it is not in Salesforce anywhere, either.

So, if a feature doesn't exist in a component, it's time to go build your own. In fact, I wrote one for a work project, because I wanted it to be able to have a custom hook when the file was selected. This hook would ultimately perform some HTMLCanvas resizing efforts to limit the maximum upload size and create web-friendly versions that would ultimately appear on our websites. I'll also say that this component only took a couple of hours of effort including styling, so it wasn't a large project.

Also, I should mention that the for="input-1" trick likely wouldn't work much longer anyways because of the new upcoming Shadow DOM. Your code would only be able to target the outermost shell as a whole, not the internal parts. Again, I really would recommend writing your own component so that you can have more control over the entire process.

  • That's basically what I was thinking. The only consideration I really have about writing a file upload component was the file size limitations I've heard about. Did you run into this at all writing yours? Jan 24, 2019 at 21:51
  • @api-testuser45690 We had a different design goal with ours. The c:fileSelector component just delivers an event with the file name, size, and blob-as-base64. The parent component ended up resizing the images to max 2000x2000 and a number of other formats as our website required, so in this case the upload limit was avoided by capping how large the images could be. If you need to deal with large files, you could upload them in chunks, etc. I would recommend splitting the file selection from the upload process for flexibility.
    – sfdcfox
    Jan 24, 2019 at 21:56
  • thanks. This is good to know. I think for now, we're going to fold in the standard upload component and put it in the backlog to roll our own. Jan 29, 2019 at 14:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .