Page MenuHomePhabricator

[desktop] Navigation arrows
ClosedPublic

Authored by michal on Nov 15 2022, 12:24 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, May 10, 10:21 AM
Unknown Object (File)
Wed, May 8, 9:52 AM
Unknown Object (File)
Sun, Apr 21, 1:10 AM
Unknown Object (File)
Sun, Apr 21, 1:10 AM
Unknown Object (File)
Sun, Apr 21, 1:10 AM
Unknown Object (File)
Sun, Apr 21, 1:10 AM
Unknown Object (File)
Sun, Apr 21, 1:10 AM
Unknown Object (File)
Sun, Apr 21, 1:10 AM
Subscribers

Details

Summary

Show navigation arrows for desktop and enable/ disable them depending on history.

  • dekstop/preload.js is running on the renderer thread (as opposed to desktop/main.js which runs on the "browser" thread) and it's often used for communication between web app and system apis. The communication between threads is achieved using IPC.
  • web/electron.js types the objects exposed in preload.js
Test Plan
  • Check if the navigation arrows are working correctly on the desktop, e.g. check that if you are in a middle of the stack and you click somewhere else the top of the stack is replaced.
  • Check if there are no changes to the web app

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

tomek requested changes to this revision.Nov 15 2022, 5:24 AM
tomek added inline comments.
desktop/main.js
38–43 ↗(On Diff #18423)

Could you explain what's happening here?

web/app.react.js
180 ↗(On Diff #18423)

Is it a good practice? When determining if we're in a browser, we're checking process.env.BROWSER. Can we take a similar approach here? Also, do all the cases where we process.env.BROWSER remain correct after introducing electron?

web/components/navigation-arrows.react.js
30 ↗(On Diff #18423)

Classnames can handle conditional classes

web/electron.js
3–11 ↗(On Diff #18423)

Is it a good practice for handling navigation in electron app?

This revision now requires changes to proceed.Nov 15 2022, 5:24 AM
ashoat added a subscriber: kamil.

I think it would be good for @kamil to review this too – he's looking at ENG-1687: Explore sqlite-worker NPM package, which is related to ENG-1685: Stateful web client, which I think has some connection to the Electron app. Given this overlap I think it makes sense for @michal to review @kamil's diffs in the space, and for @kamil to review @michal's diffs in the space.

web/electron.js
6 ↗(On Diff #18423)

This should be $ReadOnly (prefix property name with +)

7 ↗(On Diff #18423)

Can we avoid any here? Is there a flow-typed library for electron (or whatever package this is)? If not, should we introduce one?

desktop/main.js
38–43 ↗(On Diff #18423)

This is the main or the "browser" thread. Whenever we detect the user navigates somewhere we send on-navigate event, which calls the callback defined in the preload.js:4 and set in the navigation-arrows.react.js.

We calls this callback with booleans that describe if user can go back and/or forward.

web/app.react.js
180 ↗(On Diff #18423)

The preload script is used by most people for injecting variables into the renderer. And I've seen checking if the injected variables exist to determine if we are inside electron, used by a few people.

I don't think there's a way to set an env variable from the electron's main thread so that the renderer thread can see it. And if there is, we would still have to inject the variables so I don't really see a point.

web/electron.js
3–11 ↗(On Diff #18423)

The only thing the electron API is used is for determining if we can go back/ forward. As discussed in this issue it's difficult to handle this in general case.

7 ↗(On Diff #18423)

Unfortunately not, see ENG-2221.

ashoat requested changes to this revision.Nov 16 2022, 8:01 PM

What are the build failures about?

web/electron.js
7 ↗(On Diff #18497)

Can we avoid any here? Why is it necessary? Please explain in detail, not just mentioning that we don't have a libdef

This revision now requires changes to proceed.Nov 16 2022, 8:01 PM

This revision also fixes two additional issues that I haven't noticed before:

  • the onNavigate callback should be set in useEffect, and should be removed in the useEffect returned callback
  • the history should be cleared when user logs in/out. Otherwise the navigation arrows behave incorrectly after relogging.
web/electron.js
7 ↗(On Diff #18497)

I've removed the event argument completely from the web callback. I don't think the code in web can do anything useful with it anyway. It also simplifies the usage.

If you think we should keep it we could type it like this:

type Event = {
  ports: MessagePort[],
  sender: IpcRenderer,
  senderId: number,
};
type IpcRenderer = {}

IpcRenderer is empty because electron doesn't pass function that are inside to the renderer thread for security reasons.

Didn't do a full review, but left some minor suggestions

web/components/navigation-arrows.react.js
33–40 ↗(On Diff #18550)

classnames returns a string so you don't need to use React.useMemo(...) here.

(Further reading: https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/)

33–40 ↗(On Diff #18550)
atul requested changes to this revision.Nov 17 2022, 4:15 PM

Only left minor suggestions, but figure I should still Request Changes to put back on your queue.

This revision now requires changes to proceed.Nov 17 2022, 4:15 PM
web/app.react.js
132 ↗(On Diff #18550)

Good idea putting this here, thanks for thinking of that!!

web/electron.js
6–7 ↗(On Diff #18550)

Prefix with +

This revision is now accepted and ready to land.Nov 21 2022, 3:14 PM