Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provider views rewrite (.files, .folders => .partialTree) #5050

Open
wants to merge 165 commits into
base: 4.x
Choose a base branch
from

Conversation

lakesare
Copy link
Contributor

@lakesare lakesare commented Mar 29, 2024

Description


TODOs

  • For each provider, check if 1. signing in 2. checking deeply nested folders 3. downloading them 4. signing out works.
    [To reviewers: I'll do it, no need to check all providers yourselves]

TODOs for next PRs


Notes to reviewers

  • I made deliberate effort not to touch the folder structure at all (for ease of reviewing & because we didn't set our minds on which one we'd prefer yet).
  • Don't worry about 1k of added lines - this PR actually reduces the number of lines by a few hundred lines - the increase is due to test files/comments.
  • We discussed a shared .env in Slack - it's underway, but not yet fully ready.
    If you need access to a particular provider - message me, and I'll send you the credentials.

This PR spans 2.5k lines across 46 files.

I separated some PRs from this PR, however further separation will make it harder to review rather than easier, this is largely a holistic change.

I think a sane way to review this PR (apart from looking through "Files changed" on github) would be to look through the code in /uppy/packages/@uppy/provider-views folder locally in your editor - just read the files and see if they make sense/if something worries you. Most of these files were updated/rewritten.

GoogleDrive
- travelling down into folders works
- checking a file works
- breadcrumbs DONT work
Copy link
Contributor Author

@lakesare lakesare Jun 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EXPLANATION

We don't need this code, because we hide checkmarks for team drives in <ListItem/> now (see #5232).
This version was leading to a weird behaviour where the checkbox was there, but it wasn't working.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EXPLANATION

These changes are here just to remove the /* eslint-disable react/require-default-props */ line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EXPLANATION

Again - these changes are here just to remove the /* eslint-disable react/require-default-props */ line.

<span className="uppy-ProviderBrowser-user" key="username">
{username}
</span>
{username && (
Copy link
Contributor Author

@lakesare lakesare Jun 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EXPLANATION

This username && thing fixes the issue in some providers where we would see a small dot even when we don't have the username (doesn't look good).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EXPLANATION

Hugely simplifying <SearchInput/> here by making it a controlled component.
That's also why we don't need nanoid anymore.

Copy link
Contributor Author

@lakesare lakesare Jun 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EXPLANATION

Removed View.ts, all code from here moves to ProviderView.ts and SearchProviderView.ts.

Pretty much all of the code that was in the View.ts superclass needed to be moved into /utils files (code is complex enough to deserve a predictable util file that's easy to single out to work on & to unit test), so View.ts was becoming thinner and thinner as I went on.
When ProviderView.ts and SearchProviderView.ts have the same behaviour, they just use the same function from /utils now.

As a bonus, removing View.ts superclass makes the types much more straightforward, and removes "method from childClass calls a method from superClass which depends on a method from childClass" situations.

@lakesare lakesare marked this pull request as ready for review June 7, 2024 13:19
@lakesare lakesare requested review from Murderlon and mifi June 7, 2024 13:19
Copy link
Member

@Murderlon Murderlon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall very happy with the functionality! Congrats.

Unfortunately the PR is overwhelmingly big, I'm having a hard time reviewing it.

A lot of time went into this already and there are code comments, tests, and from a glance most things seem very well structured. So I don't think it makes sense to force you to split this up into many PRs.

But I would like to point out that I do see it as an expectation to know how to make small PRs, and this could've probably been 5 to 10 PRs. It's more a note for us as a team (I'm also still improving at forcing myself to make small PRs).

Comment on lines +11 to +12
// TODO: document what is a "tagFile" or get rid of this concept
const getTagFile = <M extends Meta, B extends Body>(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did it became more clear to you why this is needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[To be clear to onlookers - it's not my comment, I carried this comment over from another file]
I didn't dive into this, but can be my next PR, I'm deep enough in this context.
I'll record this in my #todos.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not too important, if you happened to know we could've add a comment :)

@lakesare
Copy link
Contributor Author

lakesare commented Jun 12, 2024

Unfortunately the PR is overwhelmingly big, I'm having a hard time reviewing it.
A lot of time went into this already and there are code comments, tests, and from a glance most things seem very well structured. So I don't think it makes sense to force you to split this up into many PRs.

Realistically the only way this could have been a set of smaller PRs is if I have been splitting this PR post-factum.

There hasn't been a way forward with a number of smaller PRs. I changed the underlying data structure multiple times as I was going through with this PR, and every such overhaul was touching most files. It's only now clear what smaller PRs could have been of use in the final version.

I can still do the post-factum split, but I don't believe it will significantly ease the review for you - the main workload of this PR is in changing the data structure used throughout provider views, which by its nature touches 40 files.

Sometimes (say, when the data structure used by all files changes completely) a big PR is unavoidable.


I understand it's challenging to review - like mentioned in the PR description, I suggest going through the folders in your editor, and seeing if it make sense. In particular would be great if the reviewers could go through code in /utils and see if it compiles in their head.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants