Move common app logic to useAppDefaults composable

[dschmidt]

Description

This extracts some file and folder loading/saving from mediaviewer and drawio apps and finally moves them into a central place.
Functions getFileInfo, putFileContents and getFileContents are based on 68b7332 by @diocas
Thanks and kudos for that!
I wanted to solve the routing a bit differently and it was easier for me to just copy the relevant parts instead of revoking parts of your commit. I hope this is fine for you, if you prefer I can probably mark the commit as being authored by us two or cherry pick and revoke the routing part. Just let me know, thanks!

Names are not great, typescript types are basically not there, the big composable file can possibly be split into more modules, etc....
This is a PoC and just lays a ground for dicussion.

Related Issue

Motivation and Context

Creating an app needs deep knowledge of the possible views in oC Web (public, private, shared, ...) and knowledge about the structure of the store. Also app code should be rather resilient against structural changes in oC Web (as much as reasonably possible at least). That is why we should provide apps a stable-ish API to run against.
This PR adds a composable providing a bunch of helper functions/properties/... usually needed to write applications handling files.
Do we need to/can we/should we consider namespace handling, too?

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

Open tasks:

• Api Concept
• Types
• Proper modularization
• Tests
• Remove dependency of web-pkg on web-app-files (?)

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[diocas]

All fine for me :)
The only reason I separated into 2 routes was to have a nicer name. But @kulmann explained that by using contextRouteName we know how to get back to the previous view... And I guess this doesn't break our (CERNBox's) universal EOS urls, so all good.

Can we apply the same logic to the external app? (I opened a similar PR for that as well)

[dschmidt]

I will look into it, my goal is certainly to unify URL handling accross all apps. For now I want to port apps shipped inside oC Web, in the long run this should become sort of a universal toolkit also for apps implemented externally.

[kulmann]

Nice unification! Didn't look into every detail, but the approach and direction this is going are nice and helpful. 👍

[dschmidt]

Naming:
We have a useDefaults composable, maybe useAppDefaults isn't a too bad name then.
packages/web-runtime/src/container/api.ts uses applicationName, so we should probably use that instead of appName here.

About the other functions and apis:
As we are not going to release this as public api too soon, we can revisit that at some point.
It should be tested, that mediaviewer and draw-io still work on all routes they support. I've only tested the personal file view and public links.

The composable can (and should) be split into more granular pieces but that can be done at a later point as well.

My linter is going bonkers and doesn't work for the whole project for me right now, so there are few pieces to fix here and there. Not only but also not using Function as type guard :)

[ownclouders]

Results for oC10SharingAccept https://drone.owncloud.com/owncloud/web/21637/15/1
The following scenarios passed on retry:

• webUISharingAcceptSharesToRoot/acceptShares.feature:108

[ownclouders]

Results for oC10IntegrationApp1 https://drone.owncloud.com/owncloud/web/21637/68/1
💥 The acceptance tests pipeline failed. The build has been cancelled.

[dschmidt]

I will look into it, my goal is certainly to unify URL handling accross all apps. For now I want to port apps shipped inside oC Web, in the long run this should become sort of a universal toolkit also for apps implemented externally.

I looked at it briefly, but not having a working wopi setup or something like that it's a bit hard for me to test and would likely bloat up this PR. In the long run we should definitely look to streamline this...

[dschmidt]

Okay, drone is green - sonarcloud probably fails because of the FIXME (right?), IMHO that's still fine. Adding types for the whole sdk client is way out of scope for this PR and I don't feel like marking it as TODO just to make sonarcloud happy :)

[dschmidt]

From my POV this is good to go!

[kulmann]

😍

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

13.8% Coverage
0.0% Duplication