Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add field name to WrapIfAdditionalTemplateProps #3896

Closed
1 task done
michal-kurz opened this issue Oct 7, 2023 · 4 comments
Closed
1 task done

Add field name to WrapIfAdditionalTemplateProps #3896

michal-kurz opened this issue Oct 7, 2023 · 4 comments
Labels
possibly close To confirm if this issue can be closed question

Comments

@michal-kurz
Copy link
Contributor

Prerequisites

What theme are you using?

core

Is your feature request related to a problem? Please describe.

I want to add a data-testid attribute to all my fields, as suggested in this issue: #1108

WrapIfAdditionalTemplate template seemed ideal for the job - something like this:

const WrapIfAdditionalTemplate = (props: WrapIfAdditionalTemplateProps) => {
  return (
    <div className={props.classNames} data-testid={xyz} style={props.style}>
      {props.children}
    </div>
  )
}

But I believe that it is currently not possible to get the field name from WrapIfAdditionalTemplateProps. WrapIfAdditionalTemplateProps.id includes it, but I don't think it's possible to parse it from there reliably, since it also includes all parent fields with separated with _, so it will be impossible to deremine for fields with underscores in name.

Describe the solution you'd like

Add field name to WrapIfAdditionalTemplateProps :)

This might be useful in other use-cases, also. I can implement this, if you point me to the conceptual solution.

Describe alternatives you've considered

Perhaps I'm missing something, and it's possible to get the name from WrapIfAdditionalTemplateProps, or perhaps it's possible to smuggle it inside there somehow :)

I also tried importing and wrapping native FieldTemplate like this:

// const FieldTempalte = getDefaultRegistry()?.templates.FieldTemplate
templates={{
  FieldTemplate: (...props) => {
    return (
      <div data-testid={xyz}>
        <FieldTempalte {...props} />
      </div>
    )
  },
}}

But surprisingly, this crashes and doesn't even render, plus this would add an additional html element wrapper, which might break some of our layouts. I would prefer to just use WrapIfAdditionalTemplateProps :)

@michal-kurz michal-kurz added feature Is a feature request needs triage Initial label given, to be assigned correct labels and assigned labels Oct 7, 2023
@heath-freenome heath-freenome removed the needs triage Initial label given, to be assigned correct labels and assigned label Oct 13, 2023
@heath-freenome
Copy link
Member

@michal-kurz Why not create a customized version of the WrapIfAdditionalTemplate? You can also use the idSeparator property on Form to switch the _ to something else (my company uses .) to support field names that contain _. Is there anything else that seems to be blocking you?

@heath-freenome heath-freenome added question awaiting response and removed feature Is a feature request labels Oct 13, 2023
@michal-kurz
Copy link
Contributor Author

@heath-freenome

You can also use the idSeparator property on Form to switch the only _ to something else

Yes, this solves my problem, didn't know you could do that, thank you very much! I'm not blocked anymore :)

Why not create a customized version of the WrapIfAdditionalTemplate?

That's what I was trying to do, if I understand you correctly. But I didn't find a way to access the field name inside my implementation of WrapIfAdditionalTemplate. But using the previous point, I can now modify the idSeparator and parse the field name from field id.

@heath-freenome
Copy link
Member

Awesome! Can I close this?

@heath-freenome heath-freenome added possibly close To confirm if this issue can be closed and removed awaiting response labels Oct 16, 2023
@stale stale bot removed the possibly close To confirm if this issue can be closed label Oct 16, 2023
@heath-freenome heath-freenome added the possibly close To confirm if this issue can be closed label Oct 28, 2023
@michal-kurz
Copy link
Contributor Author

@heath-freenome Yes, I'll close, sorry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
possibly close To confirm if this issue can be closed question
Projects
None yet
Development

No branches or pull requests

2 participants