Store options metadata in datamodel (v3) #1611

Magnusrm · 2023-10-26T14:43:34Z

Description

Allow for storing the metadata from retrieved code-lists in a specific field in the datamodel by introducing the metadata keyword to be used in dataModelBindings for components that use options.
The metada can then be displayed by referencing the datamodel field where the metadata is stored after the options have been retrieved.

"dataModelBindings": {
  "simpleBinding": "Adresse.Kommune",
  "metadata": "Adresse.KommunerMetadata"
},

Related Issue(s)

closes Add support for getting the requested URL from a codelist for documentation app-lib-dotnet#256

Verification/QA

Manual functionality testing
- I have tested these changes manually
- Creator of the original issue (or service owner) has been contacted for manual testing (or will be contacted when released in alpha)
- No testing done/necessary
Automated tests
- Unit test(s) have been added/updated
- Cypress E2E test(s) have been added/updated
- No automatic tests are needed here (no functional changes/additions)
- I want someone to help me make some tests
UU/WCAG (follow these guidelines until we have our own)
- I have tested with a screen reader/keyboard navigation/automated wcag validator
- No testing done/necessary (no DOM/visual changes)
- I want someone to help me perform accessibility testing
User documentation @ altinn-studio-docs
- Has been added/updated
  Add docs for options-metadata altinn-studio-docs#1264
- No functionality has been changed/added, so no documentation is needed
- I will do that later/have created an issue
Support in Altinn Studio
- Issue(s) created for support in Studio
- This change/feature does not require any changes to Altinn Studio
Sprint board
- The original issue (or this PR itself) has been added to the Team Apps project and to the current sprint board
- I don't have permissions to do that, please help me out
Labels
- I have added a kind/* label to this PR for proper release notes grouping
- I don't have permissions to add labels, please help me out

olemartinorg

🚀

olemartinorg · 2023-11-10T15:06:08Z

src/codegen/Common.ts

@@ -144,6 +144,13 @@ const common = {
        'Describes the location in the data model where the component should store its value(s). A simple ' +
          'binding is used for components that only store a single value, usually a string.',
      ),
+  IDataModelBindingsOptionsSimple: () =>
+    new CG.obj(new CG.prop('simpleBinding', new CG.str()), new CG.prop('metadata', new CG.str().optional()))


There should probably also be a description for the metadata prop here as well, although I'm not sure if it's easily visible from vscode that way. I know people will wonder what it's for without any docs! 😊

I'll add some description! 😁

olemartinorg · 2023-11-10T15:10:16Z

src/utils/network/networking.ts

+export async function httpGetWithHeaders(url: string, options?: AxiosRequestConfig): Promise<any> {
+  const headers = options?.headers as RawAxiosRequestHeaders | undefined;
+  const response: AxiosResponse = await axios.get(url, {
+    ...options,
+    headers: { ...headers, Pragma: 'no-cache' },
+  });
+  return response.data ? response : null;
+}


Not sure I like the name all that much.. It's not 'with headers', it's with the whole response object. Frankly I don't like the way we usually pluck out the data from the responses, so if I'm not sure if just renaming it to httpGetRaw() would be better, or if we should just stop wrapping axios entirely. Anyway, it's all fine for v3, no need to be picky there.

I agree the name is not that satisfying. I like httpGetRaw better atleast 👍. Another option is to rename this one to httpGet and the one that is httpGet today to httpGetResponseData.

Yeah, but if you're renaming all usages you might as well just use httpGet(...)?.data and just have one function to rule them all. The same then goes for all the http* functions, so I'd prefer to clean it all up or leave it be.. 😊