You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand this is a feature request and questions should be posted in the Community Forum
I searched issues and couldn’t find anything (or linked relevant results below)
Problem
Separated plugins
provider-views and companion-client always belong together and operate on each other, but they are separate plugins, and not direct dependencies of each other. Most code just references code of the other plugin, but we can't use types from the other plugin as we don't have access to it.
To prevent incorrect types and introducing a breaking change by merging the packages, I deemed the best approach to duplicate some of the types into utils (CompanionClientProvider, CompanionFile) and create UnknownProviderPlugin and UnknownSearchProviderPlugin in core.
Faulty inheritance
Another place of needless complexity, is the View base class, which is used for ProviderView and SearchProviderView (that was my abstraction 😬🔫 ). View sets the provider property on the class, but that's different for ProviderView and SearchProviderView. Some type trickery is needed for this.
The "tag file"
In Uppy we have UppyFile, CompanionFile (introduced here), and Tagfile. The last one no one understands why it's there (as seen from an existing todo comment). Having this third type going around the codebase started posing problems, as now Restricter and some methods on Uppy now needed to deal with this.
For Restricter I solved this with yet another type: ValidateableFile. There had to be a type to indicate the minimal amount of properties present in order to validate it, then all file types can have overlap with it. Unfortunately RestrictionError has to maintain UppyFile, so only in Restricter a cast from ValidateableFile to UppyFile is required to please TS.
Solution
Merge the two plugins
Remove the View class in favor of composition.
Remove the "tag file" concept. It should be possible to use UppyFile instead.
Alternatives
Don't merge the plugins, only fix the View and "tag file" problems.
The text was updated successfully, but these errors were encountered:
Initial checklist
Problem
Separated plugins
provider-views
andcompanion-client
always belong together and operate on each other, but they are separate plugins, and not direct dependencies of each other. Most code just references code of the other plugin, but we can't use types from the other plugin as we don't have access to it.To prevent incorrect types and introducing a breaking change by merging the packages, I deemed the best approach to duplicate some of the types into
utils
(CompanionClientProvider
,CompanionFile
) and createUnknownProviderPlugin
andUnknownSearchProviderPlugin
incore
.Faulty inheritance
Another place of needless complexity, is the
View
base class, which is used forProviderView
andSearchProviderView
(that was my abstraction 😬🔫 ).View
sets theprovider
property on the class, but that's different forProviderView
andSearchProviderView
. Some type trickery is needed for this.The "tag file"
In Uppy we have
UppyFile
,CompanionFile
(introduced here), andTagfile
. The last one no one understands why it's there (as seen from an existing todo comment). Having this third type going around the codebase started posing problems, as nowRestricter
and some methods onUppy
now needed to deal with this.For
Restricter
I solved this with yet another type:ValidateableFile
. There had to be a type to indicate the minimal amount of properties present in order to validate it, then all file types can have overlap with it. UnfortunatelyRestrictionError
has to maintainUppyFile
, so only inRestricter
a cast fromValidateableFile
toUppyFile
is required to please TS.Solution
View
class in favor of composition.UppyFile
instead.Alternatives
Don't merge the plugins, only fix the
View
and "tag file" problems.The text was updated successfully, but these errors were encountered: