-
Notifications
You must be signed in to change notification settings - Fork 196
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
Implement native sharing #1158
base: main
Are you sure you want to change the base?
Implement native sharing #1158
Conversation
a739d91
to
a87c6d4
Compare
@zefhemel from my side this would be ok as a first shot. As a second step, it might be nice to allow adding tags to the added entries, but that could be done in a follow-up PR as I've mostly spent the time I'm able to invest in this feature. |
Oh, the way it is currently implemented does not work in offline mode, which makes it 80% less useful... |
a87c6d4
to
ed4cbd5
Compare
handleShareTarget: | ||
path: share.ts:handleShareTarget | ||
env: client | ||
events: | ||
- http:request:/share_target |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zefhemel I guess just specifying env: client
here is not enough to trigger handleShareTarget
through an incoming http request, right?
Is there already logic to delegate http:request
events to plugs on the client side?
It looks like this would need to be done in service_worker.ts
which currently only handles read requests.
Do you think it's a good idea to enhance service_worker.ts
with dispatchEvent
logic similar to http_server.ts
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zefhemel ping 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RIght. Right now handling HTTP requests through a service worker (so fully locally and therefore offline) is not possible. It's technically possible to do, but it's not there at this moment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would service_worker.ts
be the right place? Do you see any issues with using a similar approach as on the server-side, i.e. checking the plugs if one of them wants to handle the URL?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the huge delay of this.
I like this feature, but I'd implement it slightly differently, if this would work (I don't have an environment to test this on, because I think this is an Android feature only?) I'd implement the endpoint handling "hardcoded" in the service worker. That is: in the fetch
event handler, decide on some URL (like /.share
or something), and put the logic in the service worker directly rather than in the share plug. I feel this is functionality that deserves a place directly in the SB core, not so much in a plug (it needs to be hardcoded in the manifest anyway), and implemented in the service worker it can also be done (I think) in a way that works both in online and offline mode.
A head's up: working with service worker is a bit of a pain in terms of reload behavior. In Chrome, you can have the service worker update on every reload: Still you probably need to reload your page a few times after every change to make sure you got the new service worker running before deciding things don't work ;) |
Closes #1090
handleShareTarget
method when native sharing button is used