@ScarletKuro @henon If this meets approval I'll redo the Docs page, list all the fixes, and change from draft PR. This changes MudFileUpload to follow the style of other components using context inside the ActivatorContent instead of IActivator. I also took the time to create default implementations.

In general looks good to me, but probs would require @igotinfected to look at this

Updated https://try.arctechonline.tech with this version if you want to test anything.

@Mr-Technician could you take a look too please?

Codecov Report

Attention: Patch coverage is 90.00000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 91.59%. Comparing base (be169a7) to head (293363b).

@@           Coverage Diff           @@
##              dev   #10487   +/-   ##
=======================================
  Coverage   91.59%   91.59%           
=======================================
  Files         426      426           
  Lines       13295    13312   +17     
  Branches     2558     2561    +3     
=======================================
+ Hits        12177    12193   +16     
  Misses        546      546           
- Partials      572      573    +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

In general LGTM for the built-in drag and drop functionality, however I think that the ActivatorContent is now confusing to use.

The original goal of ActivatorContent was to make it so that anything within ActivatorContent triggers the file picker, without any extra user setup. Previously you had to mess around with a label button + for attribute:

With this implementation we're asking the user to add an @onclick to define the activator.

My preference would be to keep anything within the ActivatorContent as an activation trigger for the file picker, but we could also just rename the ActivatorContent for clarity.

If I am being honest, ActivatorContent and SelectedTemplate are the wrong terms, it should be CustomContent (or something to indicate they are overriding) and FilesTemplate (or something to indicate they can customize the style of files). That being said IActivator I think caused more issues than it solved and this removes it by using context (like MudStepper and soon MudMenu). It's an easy change for people to make and doesn't require anything funny to make work, the user has full control.

I wasn't around for the label button + for, glad I missed those days! Either way I'm 100% flexible my goal was to make the component easier to use in the future while maintaining past functionality as much as possible.

That being said IActivator I think caused more issues than it solved

You're right, your implementation makes sense, it's more flexible, and less magic behind the scenes with the IActivatable. I'm happy as long as we fix up the naming and documentation surrounding usage!

As for ActivatorContent and SelectedTemplate... couldn't they just be merged now? Don't we have access to the files within the ActivatorContent context?

For naming I have no clue, CustomContent, FileUploadContent, FileUploadTemplate, ... I'll let people better at naming than me decide :')

That being said IActivator I think caused more issues than it solved

You're right, your implementation makes sense, it's more flexible, and less magic behind the scenes with the IActivatable. I'm happy as long as we fix up the naming and documentation surrounding usage!

As for ActivatorContent and SelectedTemplate... couldn't they just be merged now? Don't we have access to the files within the ActivatorContent context?

For naming I have no clue, CustomContent, FileUploadContent, FileUploadTemplate, ... I'll let people better at naming than me decide :')

So do we want to rename them now? I like the idea of them being separate so the user can use the default setup and still customize or not show the files as they choose. (For example if they upload immediately they might just want to show a progress bar)