[nuxt] add nuxt module

[Alchez]

Closes #199.

[agritheory]

This likely requires resolving #200 first

[agritheory]

If you're looking for a shortcut for User schema, this is what's minimally required for a PG-backed JWT auth workflow

And here's a schema for authentication and authorization in Postgres

[agritheory]

I can see the Users UI briefly before it shows an error in the browser: "500 crypto.randomUUID is not a function" and a differetn one in the console:

 ERROR  [nitro] [unhandledRejection] Converting circular structure to JSON
    --> starting at object with constructor 'Object'
    |     property '_context' -> object with constructor 'Object'
    --- property 'app' closes the circle

  --> starting at object with constructor 'Object'
  |     property '_context' -> object with constructor 'Object'
  --- property 'app' closes the circle
  at JSON.stringify (<anonymous>)
  at Object.toDisplayString (/home/tyler/stonecrop/node_modules/@vue/shared/dist/shared.cjs.js:463:154)
  at Module.ssrInterpolate (@vue/server-renderer:194:35)
  at _sfc_ssrRender (src/runtime/layouts/StonecropHome.vue:26:100)
  at renderComponentSubTree (@vue/server-renderer:715:9)
  at renderComponentVNode (@vue/server-renderer:664:12)
  at renderVNode (@vue/server-renderer:779:14)
  at renderComponentSubTree (@vue/server-renderer:730:7)
  at renderComponentVNode (@vue/server-renderer:664:12)
  at renderVNode (@vue/server-renderer:779:14)


 WARN  [nuxt] Failed to stringify dev server logs. Received DevalueError: Cannot stringify arbitrary non-POJOs. You can define your own reducer/reviver for rich types following the instructions in https://nuxt.com/docs/api/composables/use-nuxt-app#payload.

[Alchez]

@agritheory

I can see the Users UI briefly before it shows an error in the browser: "500 crypto.randomUUID is not a function"

This showed up in the FAB app before as well when using the ATable package, and I had helped Heather through the error here.

If we assume secure contexts across the board, then I think this is a non-issue, but if we want to ease development as well in potentially insecure contexts, then I think we should revert to using the uuid module. What do you think?

ERROR [nitro] [unhandledRejection] Converting circular structure to JSON
WARN [nuxt] Failed to stringify dev server logs. Received DevalueError: Cannot stringify arbitrary non-POJOs. You can define your own reducer/reviver for rich types following the instructions in https://nuxt.com/docs/api/composables/use-nuxt-app#payload.

These errors/warnings are coming from trying to render the Stonecrop instance object as is into the page (<pre>{{ stonecrop }}</pre>), and are safe to ignore since we'll be removing that code eventually.

[agritheory]

@Alchez Turns out this is a known WSL problem. I was trying to access it via the WSL IP which the browser has every reason to think is an insecure website. It also only works on Brave and not Firefox. That said, I think the limitations of using the browser for this are clear. Before refactoring the UUID package I think it might make sense to look at alternatives that are more performant.

[Alchez]

@agritheory It seems like if we're looking at performance, then we might want to consider nanoid. There's a bunch of performance benchmarks (1) (2) and NanoID seems to be consistently fast while generating IDs (although slower than the native crypto module). Interestingly, nanoid themselves are saying they're - on average - about half as performant than uuid.

The differences in performance also only seem to show up when you scale up the number of IDs being generated, which is currently low since they're only being used for table stores.

Should I move to nanoid or back to uuid?

[agritheory]

I think nanoid is still overbuilt for our purposes and that a randomly generated 8-character base64 hash would be fine.

[github-actions]

Coverage Report for ./atable

Status	Category	Percentage	Covered / Total
🟢	Lines	71% (🎯 70%)	169 / 238
🟢	Statements	71.71% (🎯 70%)	180 / 251
🟢	Functions	81.63% (🎯 70%)	40 / 49
🔴	Branches	50.27% (🎯 70%)	91 / 181

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
atable/src/utils.ts	100%	100%	100%	100%
atable/src/stores/table.ts	75%	51.47%	84.21%	74.72%	40-41, 54, 85-86, 106-110, 133, 137-148, 175, 183-184, 190
Unchanged Files
atable/src/components/ACell.vue	90.56%	62.5%	100%	90.38%	100, 123-126, 156, 164-166
atable/src/components/AExpansionRow.vue	0%	0%	0%	0%	33-3
atable/src/components/ARow.vue	58.33%	56.25%	50%	58.33%	50-64, 17
atable/src/components/ATable.vue	59.25%	37.5%	90.9%	58.49%	112-116, 126-154
atable/src/components/ATableHeader.vue	100%	57.14%	100%	100%
atable/src/components/ATableModal.vue	90%	75%	50%	90%	49

Generated in workflow #529 for commit 6184281 by the Vitest Coverage Report Action

[Alchez]

@agritheory I've added the router and docbuilder keys to the module options schema. Although I'm not sure how the docbuilder should unpack into the application; should it be an extra set of pages that re-implement the docbuilder example? Or should it expose the docbuilder components only?

[agritheory]

should it be an extra set of pages that re-implement the docbuilder example

Yeah, I think that's what's most helpful, but having the components available wouldn't hurt either