wip: component auto import

[agritheory]

This is a POC for automatically importing custom components into the BEAM app. #165

TBD: the actual structure of the hook in customer_app/hooks.py

This PR does not address any custom routing requirements, which is very likely required.

[github-actions[bot]]

Coverage Report

File	Stmts	Miss	Cover	Missing
__init__.py	1	0	100%
customize.py	24	24	0%	4–5, 7, 10–19, 24–32, 44–45
hooks.py	17	0	100%
install.py	34	34	0%	4, 6–7, 9–12, 15–24, 27–28, 31, 34–35, 37–38, 40, 42–43, 45, 49–50, 52–55
beam
__init__.py	0	0	100%
barcodes.py	31	13	58%	18, 27, 29, 32, 43–44, 46–47, 52–54, 58–59
boot.py	3	3	0%	4, 7–8
handling_unit.py	81	37	54%	25, 31, 63–65, 83, 94–95, 101–102, 104–105, 107–108, 110–111, 113, 115–118, 120–122, 124, 126, 128–129, 134, 136, 140, 142–143, 146, 148–149, 157
printing.py	61	61	0%	4–6, 8, 11–12, 15–16, 18–21, 24–25, 34–45, 47–54, 58–59, 61–62, 71–75, 78–79, 85–87, 90–91, 94–95, 97–99, 101–102, 104, 109, 111–112
beam/demand
demand.py	327	40	87%	25, 27–28, 31–42, 50, 65, 119, 203, 237, 281, 284, 453–454, 473–475, 480–481, 483, 485–487, 489, 533, 607, 611, 648, 654, 661
receiving.py	112	7	93%	17, 19–20, 73, 124, 165, 205
sqlite.py	59	1	98%	40
utils.py	51	5	90%	55, 66, 72–74
beam/doctype
__init__.py	0	0	100%
beam/doctype/beam_mobile_route
__init__.py	0	0	100%
beam_mobile_route.py	3	0	100%
beam/doctype/beam_settings
__init__.py	0	0	100%
beam_settings.py	11	5	54%	10, 15–18
test_beam_settings.py	3	0	100%
beam/doctype/handling_unit
__init__.py	9	3	66%	12–14
handling_unit.py	14	0	100%
test_handling_unit.py	3	0	100%
beam/doctype/warehouse_types
__init__.py	0	0	100%
warehouse_types.py	3	0	100%
beam/overrides
sales_order.py	10	6	40%	11–16
stock_entry.py	67	17	74%	61–62, 67–74, 80–81, 97, 112, 129, 132–133
work_order.py	10	2	80%	14, 16
beam/print_format
__init__.py	0	0	100%
beam/print_format/handling_unit_label
__init__.py	0	0	100%
beam/print_format/item_barcode
__init__.py	0	0	100%
beam/report
__init__.py	0	0	100%
beam/report/demand_map
__init__.py	0	0	100%
demand_map.py	34	34	0%	4–5, 7–8, 11–12, 15–16, 103–110, 126, 128–142, 145–146
beam/report/handling_unit_traceability
__init__.py	0	0	100%
handling_unit_traceability.py	44	44	0%	4–6, 9–11, 30–32, 34–35, 37–38, 41–42, 45–46, 48–49, 51–52, 54–55, 57, 63–65, 67–69, 71, 74–77, 79–81, 83–86, 89–90
beam/scan
__init__.py	124	19	84%	20, 24–25, 30, 38, 70, 117–118, 128, 130–131, 135, 139–140, 143, 173, 202, 204, 222
config.py	26	26	0%	4, 6, 9–17, 19–21, 23–26, 28–30, 32–35, 37
tests
conftest.py	28	0	100%
fixtures.py	6	0	100%
test_demand.py	278	36	87%	260–263, 272–273, 275–276, 278–279, 281–282, 305–309, 311–314, 316–318, 321–322, 324–328, 340–344
test_handling_unit.py	365	59	83%	18–19, 21–22, 482, 502, 543, 553, 580, 583–584, 587–596, 603–606, 615–617, 619–620, 622–624, 632, 639, 641–647, 649, 659–662, 671–674, 676–678, 686, 693–695, 697
test_hooks_override.py	40	0	100%
test_receiving_demand.py	46	0	100%
test_scan.py	24	0	100%
www
__init__.py	0	0	100%
demand.py	6	6	0%	4, 6, 9–12
www/beam
__init__.py	0	0	100%
index.py	7	7	0%	4, 6, 9–13
TOTAL	1962	489	75%

[Alchez]

@agritheory I think we have a few additional scenarios here (that may be inclusive with each other):

• Component discovery: If a user wants to expose a directory under which their custom Beam components would live, then we should be able to apply that via hooks too.
  • I think the structure of the hooks might be an array of paths to match the dirs property of unplugin.
  • This would allow users to develop new components in a single place without having to manually register each component, and also allow over-writing existing Beam components.
  • We could also allow users to exclude components from being registered (either explicitly via the config or by disabling sub-directory discovery and nesting components in a different or sub-directory).
• Routing: You've already covered this in #165 but additional routes could also be over-written or extended on top of the default Beam routes.

---

I'm thinking the hooks structure could look something like the following (if we wanted pure Python):

# hooks.py
beam_override = {
	"components": ["./custom_app/beam/components/"],
	# (or alternatively)
	# "components": {"Repack": "./custom_app/beam/components/Repack.vue"},
	"routes": [
		{
			path: '/repack',
			name: 'repack',
			component: "Repack.vue",
			meta: { "doctype": "Stock Entry", "requiresAuth": True },
		}
	],
}

or something like this (if we wanted to process JS/TS files directly instead):

# hooks.py
beam_override_file = "public/js/beam/setup.ts"

// setup.ts

// if we wanted to supply a directory
const dirs = ["./custom_app/beam/components/"]

// if we wanted to explicitly define components
import Repack from "./custom_app/beam/components/Repack.vue"
const components = { Repack: Repack }

// if we wanted to over-write/extend routes
const routes = [
	{
		path: '/repack',
		name: 'repack',
		component: Repack,
		meta: { "doctype": "Stock Entry", "requiresAuth": true },
	}
]

export {
	dirs,
	components,
	routes
}

The latter approach might also allow us to pass existing context to do stuff like dynamic routing.

This hook would be read in the Vite entry-file and the routes and components set up based on the priority order of: Custom App > Beam (default).

What do you think?

[agritheory]

@Alchez hooks.py Is the appropriately default configuration file for a Frappe project, I think it's where we want to be. If functions are required, they can be serialized to JSON, which we're already doing in ATable's format function for example.

I it does make sense to respect a "just a directory" approach as well as listing individual files. These approaches can be combined with a "*" key:

        "components": ["./custom_app/beam/components/"],
	# (or alternatively)
	# "components": {"*": "./custom_app/beam/components/"},
	# "components": {"Repack": "./custom_app/beam/components/Repack.vue"},

[agritheory]

@Alchez Got in some time on this this afternoon with the following WIP:

• hooks resolve in the apps resolution order as specified in apps.json
• Moved route and component config to hooks.py so the can be more easily overridden in config by client apps as needed
• Builds successfully but without importing the components or routes. That's based on this work that I didn't completely understand but seemed like a promising route
• Typing needs some attention, TS is not a fan of me saying "it's an object, what's the problem"
• We want the /home page to be configurable in the UI and role restricted, but that's a future step built on this work