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

Customize id prefix of root_ from rendered DOM #796

Closed
2 tasks done
edi9999 opened this issue Jan 4, 2018 · 8 comments
Closed
2 tasks done

Customize id prefix of root_ from rendered DOM #796

edi9999 opened this issue Jan 4, 2018 · 8 comments

Comments

@edi9999
Copy link
Collaborator

edi9999 commented Jan 4, 2018

Prerequisites

  • I have read the documentation;
  • In the case of a bug report, I understand that providing a SSCCE example is tremendously useful to the maintainers.

Description

The bug is that the generated DOM contains ids, which are not guaranteed to be unique, if for example I have two forms on the same page.
I think we should not use ids at all in the generated DOM, but probably if we want to identify fields, we could use data attributes such as :

<input data-rjsf={id}/>

Actual behavior

The generated DOM is full of ids.

See this example :

  <fieldset>
    <legend id="root__title">A registration form</legend>
    <p id="root__description" class="field-description">A simple
    form example.</p>
    <div class="form-group field field-string">
      <label class="control-label" for="root_firstName">First
      name*</label><input type="text" class="form-control" value=
      "Chuck" id="root_firstName" label="First name" required=""
      placeholder="">
    </div>
    <div class="form-group field field-string">
      <label class="control-label" for="root_lastName">Last
      name*</label><input type="text" class="form-control" value=
      "Norris" id="root_lastName" label="Last name" required=""
      placeholder="">
    </div>
    <div class="form-group field field-integer">
      <label class="control-label" for="root_age">Age of
      person</label>
      <p id="root_age__description" class="field-description">
      (earthian year)</p><input type="number" class="form-control"
      value="75" id="root_age" label="Age" placeholder="">
    </div>
    <div class="form-group field field-string">
      <label class="control-label" for="root_bio">Bio</label>
      <textarea id="root_bio" class="form-control" placeholder=
      "">Roundhouse kicking asses since 1940</textarea>
    </div>
    <div class="form-group field field-string">
      <label class="control-label" for=
      "root_password">Password</label><input type="password" class=
      "form-control" value="noneed" id="root_password" label=
      "Password" placeholder="">
      <p class="help-block">Hint: Make it strong!</p>
    </div>
    <div class="form-group field field-string">
      <label class="control-label" for=
      "root_telephone">Telephone</label><input type="tel" class=
      "form-control" value="" id="root_telephone" label="Telephone"
      placeholder="">
    </div>
  </fieldset>

Version

1.0.0

@Natim
Copy link
Contributor

Natim commented Jan 4, 2018

I think the purpose of having ids everywhere is to allow you to add specific css rules if needed. Why would you think it is an issue to have them?

@edi9999
Copy link
Collaborator Author

edi9999 commented Jan 4, 2018

Actually, I think we need ids to link label with input.

The problem with these ids is that they can be duplicated.

@Natim
Copy link
Contributor

Natim commented Jan 4, 2018

The problem with these ids is that they can be duplicated.

Yes good catch.

@edi9999
Copy link
Collaborator Author

edi9999 commented Jan 4, 2018

My suggestion was to use data-rjsf={id} instead of id={id}, which you can also select with css rules with :

[data-rjsf="root_password"]

This doesn't pollute the "global" id namespace.

@Natim
Copy link
Contributor

Natim commented Jan 4, 2018

Would this work for label for attribute? What about rjsf_root_password instead?

  • It stays an ID
  • It adds a namespace

@edi9999
Copy link
Collaborator Author

edi9999 commented Jan 4, 2018

Yes, I think it would be good to have rjsf_root_password instead,

maybe to be able to do this in the current version without losing backwards compatibility, the "prefix" for id could be an option :

<Form
   uiSchema={uiSchema}
   idPrefix="rjsf_"
   ...
>

And idPrefix would be by default "" (empty string)

@Natim
Copy link
Contributor

Natim commented Jan 4, 2018

@edi9999 do you feel like starting a Pull-Request to start implementing that proposal?

@edi9999
Copy link
Collaborator Author

edi9999 commented Jan 4, 2018

I will see if I have some time for this, but it is not guaranteed.

@edi9999 edi9999 changed the title Remove id from rendered DOM Customize id prefix of root_ from rendered DOM Jan 10, 2018
edi9999 added a commit to edi9999/react-jsonschema-form that referenced this issue Jan 11, 2018
jnorris-carecloud added a commit to CareCloud/react-jsonschema-form that referenced this issue Jul 2, 2018
* Fix rjsf-team#221: No validating but updating errorSchema base on array operation when live validation is off.

* Fix comparing

* Directly update errorSchema in onChange

* Typo fix (rjsf-team#737)

* Make form submission example clearer (rjsf-team#736)

In the example, the `onSubmit` function receives a `formData` obj. However, the actual data is in `formData.formData`. While this is explained in the docs, I propose making it clearer in the example as well.

* Update prettier to v1.8.2 (rjsf-team#756)

* fix: Pass `disabled` prop to `FieldTemplate`. (rjsf-team#741)

If you want to change how your FieldTemplate is rendered based on
ui:disabled, you currently have to check `uiSchema["ui:disabled"]`,
which is unlike the pattern for `readonly` and other known `ui:*`
settings.

* Fix issue rjsf-team#747 (rjsf-team#748)

* 66 enum no type (rjsf-team#668)

* Failing test for enum without type (rjsf-team#66 rjsf-team#611)

* Proposed fix for enum without type (rjsf-team#66 rjsf-team#611)

* PR feedback - getSchemaType function

https://github.com/mozilla-services/react-jsonschema-form/pull/668/files#r133395455

* Fix onAddClick signature in ArrayFieldTemplate (rjsf-team#775)

According to https://github.com/mozilla-services/react-jsonschema-form/blob/master/src/components/fields/ArrayField.js#L224 `onAddClick` is not returning function as specified in the documentation.

* fix typo in css code (rjsf-team#799)

* README: fix code snippet (rjsf-team#785)

* Generating idSchema based on dependency changes Fix rjsf-team#778 , Fix rjsf-team#803

* Add idPrefix option (Fix rjsf-team#796) (rjsf-team#806)

* Make .editorconfig valid (rjsf-team#807)

* typo (rjsf-team#811)

* Add span and class to label required symbol (rjsf-team#765)

* a priori should be italicized for readibility (rjsf-team#825)

* Priori should by prior, I think

* Italicizing a priori based on suggestion

* pass raw errors to  field widgets (rjsf-team#826)

* pass raw errors to  field widgets

* fixed formatting

* fixing line endings

* Pass raw errors into Field at creation; object destructuring; added test for passing of raw errors; removed unused prop from ArrayField.

* fix lineEndings

* Bump 1.0.1

* Move to the 3.x series of react-codemirror2 (rjsf-team#857)

* Move to the 3.x series of react-codemirror2

* Move to the 4.x series of react-codemirror2

See scniro/react-codemirror2#63 for more details.

* Pass formContext to ArrayFieldTemplate when rendering fixed array (rjsf-team#858)

* handle errors to correctly display schema errors in form (rjsf-team#864)

* Bump version 1.0.2

* Link to official JSON Schema site (rjsf-team#873)

* Updated README to mention the support from JSON Schema compliant drop-down enums (rjsf-team#882)

* Add passing of raw errors to ArrayField template and components (rjsf-team#876)

* Fixed multiplicative errors on schema dependencies (rjsf-team#884)

* Add idPrefix option (rjsf-team#883)

* Fix warning on FileWidget (rjsf-team#842)

* Update prettier and fix files (rjsf-team#892)

* Bump 1.0.3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants