Open jasonkuhrt opened 4 years ago
A few thoughts:
app.settings.plugins.prisma.crud.relations.createable = false
I find this quite terrible 😢. As much as I understand the reasoning for considering the approach, the level of nesting is just too much if we ever get there. I'd rather have a nested object..
to keep the mental model simple, app.settings should make its data readable in plain form:
We currently use the approach of having app.settings
being both a "reader" and a "writer". This raised the drawback of having the function prototype in the autocomplete of app.settings
. We could simplify things by having app.settings.set({ ... })
and app.settings.get().*
. It's not very elegant, but also still keeps "the mental model simple"
Take inspiration from https://fastapi.tiangolo.com/advanced/settings/
What
Configuration keeps coming up, see related (below) for examples
autocompletion and jsdoc should be optimized for
so many questions/ways we could do this...
function-object approach:
object approach:
function-object and object approaches could be combined
some screenshot / dx observations:
vscode gives awkward autocomplete for objects when curly braces are broken across lines.
vscode/ts does not give a preview of the settings one can set on param preview (is case for both
type = ...
andinterface = ...
)user has no autocomplete with object unless they know how to summon the autocomplete with hotkey (ctrl-space). Even if they know, unclear how well that fits into their flow (e.g. they only know how via menu or have awkward bindings or are on a friend's computer with different customizations, ...)
errors can be visually loud
error information can be non-trivial
working with object properties leads to clean autocomplete compared to above:
function-object approach however is JS idiomatic and a succinct experience
to keep the mental model simple,
app.settings
should make its data readable in plain form:so even with function-object for writes there would still be object for reads
at that point, might as well permits writes and leave it up as a style decision? object read/write is the most "basic" but the function-object is there for sugar
about hierarchy
Sometimes duplicated read/write fields under different paths might be nice. Take the experiments system for example:
Basically When something could be distributed or centralized, we should do both so that the user doesn't have to remember.
app.settings.plugins.prisma
might affect how nexus-prisma will behave during nexus schema timesettings.ts
conventionRelated
Places where need for config has come up:
141
296