feat(api): add abstractions to updater and window event listeners by lucasfernog · Pull Request #4569 · tauri-apps/tauri

lucasfernog · 2022-07-02T12:40:50Z

What kind of change does this PR introduce?

Does this PR introduce a breaking change?

Yes, and the changes were approved in issue #___
No

Checklist

When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
I have added a convincing reason for adding this feature, if necessary

Other information

lucasfernog · 2022-07-02T12:41:08Z

@FabianLars is this what you had in mind? :P

FabianLars · 2022-07-02T13:52:08Z

Well initially i just wanted better docs, but you had me intrigued with this idea and you were right, this is indeed wayyy better, especially for typescript users because they don't have to handle the types themselves with this. I like it! 👍

I liked that it used to be uncoupled from appWindow tho, but i guess that's a fair trade-off (and it's not like you can't use the old way anymore)

lucasfernog · 2022-07-03T23:40:33Z

what do you mean by uncoupled from appWindow @FabianLars ? you still needed it to call .listen.

lucasfernog · 2022-07-03T23:50:14Z

@JonasKruckenberg I've followed #3731 here, anything you want to change?

FabianLars · 2022-07-04T09:19:30Z

what do you mean by uncoupled from appWindow @FabianLars ? you still needed it to call .listen.

For me it's just listen > appWindow.listen, that's all lol.
For users that use their frontend in both tauri and a normal browser appWindow likes to cause problems, but whatever. It's not that big of a deal and you still can listen to the events manually.
All good, just wanted to mention it for whatever reason sorry 🤷

Edit: Oh another "side-effect" that somewhat came up on discord is that this abstraction makes it less obvious that you have to unlisten when the component unmounts (at least in React)

lucasfernog · 2022-07-04T11:29:43Z

From an API perspective the events are tied to the appWindow though, so they'll have to be a little smart with the bundler config to only import appWindow for tauri builds - or inject dummy values.

Why does it make it "less obvious"? You're still just listening to an event - and it still returns the unlisten function.

JonasKruckenberg

If you're goal here is to improve the DX especially when using TS, might I suggest doing a simple overload of the listen instead? All these separate handlers add a lot of code while not really feeling all that iditomatic

  async listen(event: 'tauri://scale-change', handler: EventCallback<ScaleFactorChanged>): Promise<UnlistenFn>
  async listen(event: 'tauri://menu', handler: EventCallback<string>): Promise<UnlistenFn>
  async listen(event: 'tauri://file-drop', handler: EventCallback<{ type: 'drop', paths: string[] }>): Promise<UnlistenFn>
  async listen(event: 'tauri://file-drop-hover', handler: EventCallback<{ type: 'hover', paths: string[] }>): Promise<UnlistenFn>
  async listen(event: 'tauri://file-drop-cancelled', handler: EventCallback<{ type: 'cancel' }>): Promise<UnlistenFn>
  async listen(event: 'tauri://theme-changed', handler: EventCallback<Theme>): Promise<UnlistenFn>
  async listen(event: 'tauri://close-requested', handler: EventCallback<CloseRequestedEvent>): Promise<UnlistenFn>
  async listen<T>(event: EventName, handler: EventCallback<T>): Promise<UnlistenFn> {
     // actual implementation
  }

JonasKruckenberg · 2022-07-04T16:11:01Z

tooling/api/src/updater.ts

  shouldUpdate: boolean
 }

+async function onUpdaterEvent(


Ideally this would be one object updater which has methods and is an event emitter, so people can use the proper .addEventListener('<updater-event>', () => {}) JavaScript idiomatic style. But for the same of not breaking this this is pretty good 👍🏻

let's add that to the v2 todo list 😂

lucasfernog · 2022-07-04T16:28:30Z

It adds a lot of code on our end, but it reduces the boilerplate on the devs code. Also it'll look better in the documentation page and it'll be easier to search (I think).

JonasKruckenberg · 2022-07-04T16:34:12Z

It adds a lot of code on our end, but it reduces the boilerplate on the devs code. Also it'll look better in the documentation page and it'll be easier to search (I think).

Hmmmm yeah I see that 🤔
alright fine by me 👍🏻

JonasKruckenberg · 2022-07-04T16:38:13Z

tooling/api/src/window.ts

+   * @param handler
+   * @returns A promise resolving to a function to unlisten to the event.
+   */
+  async onFileDropEvent(


Wdyt about making FileDropEventa proper DragEvent instead? https://developer.mozilla.org/en-US/docs/Web/API/DragEvent

I think we can file a feature request for that.

JonasKruckenberg · 2022-07-04T16:38:49Z

tooling/api/src/window.ts

+   * @returns A promise resolving to a function to unlisten to the event.
+   */
+  async onCloseRequested(
+    handler: (event: CloseRequestedEvent) => void


Suggested change

handler: (event: CloseRequestedEvent) => void

handler: EventCallback<CloseRequestedEvent>

These are not the same, EventCallback<CloseRequestedEvent> translates to (event: Event<CloseRequestedEvent>) => void and we're wrapping the event fields in the CloseRequestedEvent directly (just to add the preventDefault method).

JonasKruckenberg · 2022-07-04T16:40:51Z

tooling/api/src/window.ts

+   * @param handler
+   * @returns A promise resolving to a function to unlisten to the event.
+   */
+  async onFocusChanged(handler: EventCallback<boolean>): Promise<UnlistenFn> {


Same here, shouldn't we be reusing DOM concepts as much as possible? I.e. make this FocusEvent https://developer.mozilla.org/en-US/docs/Web/API/FocusEvent with relatedTarget set to null

I think we can file a feature request for that.

JonasKruckenberg · 2022-07-04T16:41:52Z

Only have one real change suggestion and two ideas for improvements/aliging with web standards that are not blocking

FabianLars · 2022-07-04T21:28:36Z

From an API perspective the events are tied to the appWindow though, so they'll have to be a little smart with the bundler config to only import appWindow for tauri builds - or inject dummy values.

Yeah just a really minor "drawback" (wouldn't even call it that), but again, nothing to worry/think about 🤷

Why does it make it "less obvious"? You're still just listening to an event - and it still returns the unlisten function.

I know how stupid it sounds, but "less obvious" because it moves further away from addEventListener.
That said we should probably add a note about it somewhere (faq?) either way, because this comes up often enough already with listen.

lucasfernog · 2022-07-04T22:27:51Z

I think we should add a note for it on every listen function lol

lucasfernog · 2022-07-05T18:47:33Z

@FabianLars better with the docs change now?

FabianLars · 2022-07-05T18:54:23Z

Yep, i like it 👍

lucasfernog requested a review from a team as a code owner July 2, 2022 12:40

lucasfernog requested a review from FabianLars July 2, 2022 12:41

feat(api): add abstractions to updater and window event listeners

9c151e2

lucasfernog added 2 commits July 3, 2022 20:48

add onCloseRequested usage to API example

f8d248d

Merge branch 'dev' into feat/listen-abstractions

d94f54f

adjust function names

1c29cba

FabianLars previously approved these changes Jul 4, 2022

View reviewed changes

lucasfernog dismissed FabianLars’s stale review via 5783fde July 4, 2022 15:50

Merge branch 'dev' into feat/listen-abstractions

5783fde

JonasKruckenberg reviewed Jul 4, 2022

View reviewed changes

JonasKruckenberg suggested changes Jul 4, 2022

View reviewed changes

lucasfernog added 2 commits July 5, 2022 09:10

Merge remote-tracking branch 'origin/dev' into feat/listen-abstractions

dc12d19

enhance docs [skip ci]

2145e30

lucasfernog merged commit b02fc90 into dev Jul 5, 2022

lucasfernog deleted the feat/listen-abstractions branch July 5, 2022 19:57

	handler: (event: CloseRequestedEvent) => void
	handler: EventCallback<CloseRequestedEvent>

Uh oh!

Conversation

lucasfernog commented Jul 2, 2022

What kind of change does this PR introduce?

Does this PR introduce a breaking change?

Checklist

Other information

Uh oh!

lucasfernog commented Jul 2, 2022

Uh oh!

FabianLars commented Jul 2, 2022

Uh oh!

lucasfernog commented Jul 3, 2022

Uh oh!

lucasfernog commented Jul 3, 2022

Uh oh!

FabianLars commented Jul 4, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lucasfernog commented Jul 4, 2022

Uh oh!

JonasKruckenberg left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lucasfernog commented Jul 4, 2022

Uh oh!

JonasKruckenberg commented Jul 4, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JonasKruckenberg commented Jul 4, 2022

Uh oh!

FabianLars commented Jul 4, 2022

Uh oh!

lucasfernog commented Jul 4, 2022

Uh oh!

lucasfernog commented Jul 5, 2022

Uh oh!

FabianLars commented Jul 5, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

FabianLars commented Jul 4, 2022 •

edited

Loading

JonasKruckenberg left a comment •

edited

Loading