Support for OCA API?

[joschaschmiedt]

For the development of NextCloud apps typings for the OCA API would be useful. As far as I can see nextcloud-typings currently only has types for OC. Is this planned? Am I missing something?

[joschaschmiedt]

I just realized that a similar issue for the docs exists: https://github.com/nextcloud/documentation/issues/894

[ChristophWurst]

https://github.com/nextcloud/documentation/issues/894 and that's still true in my understanding. OCA isn't any kind of public API. You're not supposed another app's APIs (if any) this way.

Anything in OC is also more or less deprecated. Or put differently, the apps were never an official API. Try to use a @nextcloud/* node package instead if possible: https://docs.nextcloud.com/server/stable/developer_manual/digging_deeper/javascript-apis.html#npm-packages

[joschaschmiedt]

Hm, I see. The particular methods I was looking at are from the files app as I was trying to extend the new file menu according to the docs: https://docs.nextcloud.com/server/19/developer_manual/app/view/js.html#extending-the-new-menu-in-the-files-app

For editor-like apps, also the OCA.Files.fileActions might be useful. Is there a @nextcloud npm package for that?

[ChristophWurst]

Not yet.

cc @skjnldsv for anything Files API related

[skjnldsv]

OCA isn't any kind of public API. You're not supposed another app's APIs (if any) this way.

Well, we should maybe migrate the OCA.Viewer to those OCP scope then? Javascript APIs are not greatly handled it seems

EDIT

• OCA.Comments.View
• OCA.Files.Settings
• OCA.Files.Sidebar
• OCA.Sharing.ShareSearch
• OCA.Sharing.ExternalLinkActions
• OCA.Sharing.ExternalShareActions
• OCA.Viewer

Maybe even some more? OCA.Talk @nickvergessen ?

[ChristophWurst]

But OCP is not an official API either. I don't think moving it from OCA to OCP gets us anywhere.

I'd rather have an @nextcloud/viewer where apps can ship and load their viewer. Then there are no global variable dependencies, the functionality works without the viewer app to be enabled and there is at least one request less per page load. Just an idea and not really relevant to this discussion.

[skjnldsv]

• OCA.Comments.View
• OCA.Files.Settings
• OCA.Files.Sidebar
• OCA.Sharing.ShareSearch
• OCA.Sharing.ExternalLinkActions
• OCA.Sharing.ExternalShareActions
• OCA.Viewer

Maybe even some more? OCA.Talk @nickvergessen ?

[skjnldsv]

But OCP is not an official API either. I don't think moving it from OCA to OCP gets us anywhere.

I'd rather have an @nextcloud/viewer where apps can ship and load their viewer.

I like the sound of this. I'd like us to discuss that a bit more. The issue though is that you cannot use vanilla javascript anymore then. OCA.Files.Actions for example makes sense, as lots of actions are quite simple.

Then there are no global variable dependencies, the functionality works without the viewer app to be enabled

I'm guessing you need to share the same context, even if apps import said library independently anyway? You'd still have a global variable somewhere I assume?

EDIT: https://github.com/nextcloud/nextcloud-event-bus/blob/631bb6172de8c955adf8f2e9999ca96ad3a17d9f/lib/index.ts#L8 I assume you meant "accessible" ones ?

[ChristophWurst]

For the viewer I suppose there is nothing we need to register globally, do we? The event bus does indeed use a global variable because we have to make sure there is exactly one instance of the bus, because if everyone has their own instance than you can't send events between components/apps :)

Yet the global is an implementation detail. Apps do not and should not access any of the globals directly. But that's just how I see it.

[skjnldsv]

For the viewer I suppose there is nothing we need to register globally, do we?

Yes, like sidebar, you have external providers. Any app can register a mimetype support for viewer. Any app can register a new tab for Sidebar :)

[susnux]

I just faced the problem of missing typings for OCA, so I disagree with:

OCA isn't any kind of public API. You're not supposed another app's APIs (if any) this way.

My use case is the workflow engine, as you are required to register new operators using

OCA.WorkflowEngine.registerCheck(Plugin);
// and
OCA.WorkflowEngine.registerOperator(Plugin);

So as this belongs to nextcloud server, I think it should be exposed by this typings package or moved to the OC namespace? (if not provising a @nextcloud/flow package).