feat(frontend): expose api interactions to plugins

[matmair]

Moves some fundamental API functions to the lib space:

• useInstance
• useModal (and useModalState)
• useApiFormModal
• useCreateApiFormModal
• useEditApiFormModal
• useBulkEditApiFormModal
• useDeleteApiFormModal
• OptionsApiForm
• ApiForm
• CreateApiForm
• EditApiForm
• DeleteApiForm

This helps plugin devs that work close to the default API pattern by reducing manual coding effort massively.

[netlify]

✅ Deploy Preview for inventree-web-pui-preview ready!

Name	Link
🔨 Latest commit	6c8e1f6
🔍 Latest deploy log	https://app.netlify.com/projects/inventree-web-pui-preview/deploys/69f7d33f354a8e0008f2efb1
😎 Deploy Preview	https://deploy-preview-11858--inventree-web-pui-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 97 (🟢 up 4 from production) Accessibility: 81 (no change from production) Best Practices: 92 (🔴 down 8 from production) SEO: 78 (no change from production) PWA: - View the detailed breakdown and full score reports
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[matmair]

This is WIP; still need to untangle a few things

[SchrodingersGat]

@matmair are you aware that plugins can already launch forms, using the hooks as listed above?

These are passed through dynamically via the InvenTreePluginContext - allowing the plugin to simply call a function which launches a form (much like a DLL). All the plugin knows about is the call type and return type for these functions.

[matmair]

i have tried working with that, but I am running into a bunch of state management issues and reimplementing a bunch of stuff like useInstance. Writing 4k lines of code for getting ui for 3 simple models with tables is unacceptable imo

[SchrodingersGat]

Writing 4k lines of code for getting ui for 3 simple models with tables is unacceptable imo

Check out this more recent plugin I have written:

https://github.com/SchrodingersGat/inventree-manufacturing-costs/blob/main/frontend/src/RateTable.tsx

The frontend code is mostly just re-using existing components (including the entire table framework).

If you can get it working this way, that's great! I had huge issues with the following:

Multiple React Versions

If you expose the components to lib and then compile into the plugin, any hooks which are used within the re-used components throw lots of errors related to running multiple versions of react. I never worked out a way around this, and so the "solution" was to pass handlers to the components through at run-time

Translation

Trying to get any translated components working within the plugin context was a nightmare. So, the build process dynamically hooks lingui to point to the one running in the browser

---

If you manage to get it working this way it's probably going to be cleaner, I'll be interested to see what you come up with!