You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we just query the component database with a glob of all the information we can get our hands on for a given component.
Perhaps instead we should consider existing schemas; eg. e-datasheets, though they exhibit this problem: edatasheets/digital-datasheets#87
Additionally, the queries should be structured better based on params the user-side knows the server side will have as data. Perhaps we should use the generics as the schema and only transport over the data we know the database will have, in the form (eg. ranges) we know it'll have it.
This is required to improve error handling and UX on the CLI side.
We should be able to throw errors like "Component missing 'value'" for example and enforce field population.
The text was updated successfully, but these errors were encountered:
Currently, we just query the component database with a glob of all the information we can get our hands on for a given component.
Perhaps instead we should consider existing schemas; eg. e-datasheets, though they exhibit this problem: edatasheets/digital-datasheets#87
Additionally, the queries should be structured better based on params the user-side knows the server side will have as data. Perhaps we should use the generics as the schema and only transport over the data we know the database will have, in the form (eg. ranges) we know it'll have it.
This is required to improve error handling and UX on the CLI side.
We should be able to throw errors like "Component missing 'value'" for example and enforce field population.
The text was updated successfully, but these errors were encountered: