podman-desktop icon indicating copy to clipboard operation
podman-desktop copied to clipboard

Create `api` package for sharing code between `main` and `renderer`

Open benoitf opened this issue 11 months ago • 4 comments

Is your enhancement related to a problem? Please describe

With electron, there are like 3 main packages, preload, main and renderer

but for example renderer can call main API to grab like a list of containers, it returns objects defined in main package using imports like '../../../main'

The problem is that you may import code that has some dependency to some Node.js classes/interfaces and it's failing

Describe the solution you'd like

To have a better scope dependency, we should import the definition from main and renderer from another package

move src/plugin/api to its own 'api' package

so, api will be for internal api, extension-api for the extension API

and both main and renderer package will be able to import from api

a new alias should be added like /@api to ease the import from both main and renderer packages

Describe alternatives you've considered

No response

Additional context

No response

benoitf avatar Mar 07 '24 11:03 benoitf

Why having a / before the @api ? why not using have @api ?

Moreover, I feel like @api would be maybe weird. At some point we might need to share more than the src/plugin/api (or not?).

Why not using something more generic like @shared or @common ?

For example let's say I need some utility methods to sort an array, or something, do I put it in the @api folder, or do I duplicates it since it not an api ?

axel7083 avatar Mar 08 '24 09:03 axel7083

Why having a / before the @api ? why not using have @api ?

Usually when it starts with @ it means it's a global package on npmjs whereas if it starts with a / it means local to the project

it avoids any name collision (as it is also the case for example why now we import node:fs and not fs

so you're sure it'll never mismatch/default to an import on npmjs

Why not using something more generic like @shared or @common ?

Because the goal is to move something that is implemented in main and used in renderer part (or preload)

I don't see many usage of methods being shared between main and renderer as basically you can't use node.js imports.

benoitf avatar Mar 08 '24 09:03 benoitf

Can I work on this issue @benoitf ?

axel7083 avatar Mar 11 '24 08:03 axel7083

it's for the next sprint, assignment will occur probably tomorrow but I've taken notes on your interest 👍

benoitf avatar Mar 11 '24 08:03 benoitf