feat(Forms): add Bring API connector for postal code validation and autofill city

[tujoworker]

• Preview: Bring connector
• Fully Treeshakeable: Ensures no unused code is bundled.
• Flexible and Extendable: Designed to adapt to future needs.
• Leverages Existing APIs: Built on current field props and APIs.

Example code:

import { Form, Connectors } from '@dnb/eufemia/extensions/forms'

// 1. Create a context with the config
const { withConfig, handlerId } = Connectors.createContext({
  fetchConfig: {
    url: '...',
    headers: {
      'X-Mybring-API-Uid': '',
    },
  },
})

// 2. Use the context to create the onChangeValidator and onChange functions
const onChangeValidator = withConfig(Connectors.Bring.postalCode.validator)

// Should we name ".postalCode.onChange" to ".postalCode.autocompleteOnChange" or something like that?
const onChange = withConfig(Connectors.Bring.postalCode.autofill, {
  cityPath: '/city',
})

render(
  <Form.Handler
    id={handlerId}
  >
    <Field.PostalCodeAndCity
      postalCode={{
        path: '/postalCode',
        onChange,
        onChangeValidator,
      }}
      city={{
        path: '/city',
      }}
    />
  </Form.Handler>
)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
eufemia	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 16, 2025 7:46pm

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[langz]

Not super duper important, as Norwegian(4-digit postal codes) is the most important.
But when playing with the great example https://eufemia-git-feat-forms-api-connectors-bring-eufemia.vercel.app/uilib/extensions/forms/Connectors/Bring/ by selecting Sweden(5-digit postal codes) as country, the requests seems to be sent when entering a postal code with 4-digits, as well as 5-digits. I don't think we need/should send the request when entering a 4-digit postal code and country is sweden 🤔

Screen.Recording.2025-02-12.at.13.17.16.mov

[tujoworker]

I don't think we need/should send the request when entering a 4-digit postal code and country is Sweden

Yes, I also thought about it. And that's why I think, its still easier to implement with the onBlurValidator, when we always send the request on blur. I get it, that instant feedback is nice, if we know the amount of characters. But when we don't know it, then 🤷‍♂️ (I don't think we should keep a list of all possible lengths. But maybe there are good arguments for that too? Let me know.)

[langz]

What does e.gc. mean?

[langz]

👍

[langz]

Suggested change

	Here is an example of how to create a validator:
	Here is an example of how to create a validator connector:

validator, is that the correct word?
On the line above it says Connectors are created by returning a function that takes the generalConfig as an argument.

Shouldn't we rather provide an example of how to create a connector rather than a validator?
Or perhaps a validator is a connector? Anyhow, it's a bit confusing when reading it.

[tujoworker]

I will enhance this section. Also now that we have a response resolver, I think it's worth to mention it.

[langz]

In the example provided, could/should we make a new API request when changing the country?
In the following video, it does not trigger an API call and/or validation when changing the country:

Screen.Recording.2025-02-16.at.14.38.47.mov

[langz]

I don't think we need/should send the request when entering a 4-digit postal code and country is Sweden

Yes, I also thought about it. And that's why I think, its still easier to implement with the onBlurValidator, when we always send the request on blur. I get it, that instant feedback is nice, if we know the amount of characters. But when we don't know it, then 🤷‍♂️ (I don't think we should keep a list of all possible lengths. But maybe there are good arguments for that too? Let me know.)

Yes, that sounds smart, making it an onBlurValidator would solve this 🙏
Or else we would have to know the possible lengths of postal codes for all countries supported by Bring's API, but that might also change? What do I know

Would be safer to execute the validation on onblur, and isn't that also what we suggest/recommend on regular input fields, to use onBlurValidator?

[tujoworker]

In the example provided, could/should we make a new API request when changing the country?
In the following video, it does not trigger an API call and/or validation when changing the country:

It does actually make a new request when testing with a real API 👍

connector.mov

[tujoworker]

🎉 This PR is included in version 10.64.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀