-1

This happens both with the lightning-record-form, and using lightning-record-edit-form when defining a field with lightning-input-field with a "time" field. Instead of showing a dropdown list to pick times from, it's just a simple input box. It also broken in that it requires HH:mm:ss time format instead of natural "hh:mm a" format.

I first noticed this when I wanted to call a native form and since Salesforce Lightning native forms are made in Aura, the equivalent is to use lightning-record-form in LWC. Of course, it looks nothing like the native salesforce one when doing the same form call in Aura Components, but I wasn't expecting the time field to be soo broken like that, to the point that it's useless.

Outside of making a custom form, or hacking up lightning-input-field and having awkward validation errors (mismatch; replacing non-input-fields with regular fields doesn't show validity errors at the same time), is there a solution to this? Is this a known issue??

EDIT# This is not a duplicate question because the one linked is for "AURA", not LWC. Thanks.

0

2 Answers 2

0

For time field you need to use

<lightning-input type="time"
             label="Time Field"
             name="timeField">
</lightning-input>

Following fields are supported in record edit form:

  1. Address: Displays the input address fields, without Google address search capability.
  2. Checkbox: Displays a checkbox input.
  3. Currency: Displays an input field for entering monetary data. The user’s Salesforce locale determines the currency symbol and separator characters used to format the number. Specifying a different locale is currently not supported for currency.
  4. Date: Displays an input field for entering a date. The date format is automatically validated against the user’s Salesforce locale format. On mobile devices, fields of type date use native mobile date pickers.
  5. Date/Time: Displays input fields for entering a date and time. The date and time formats are automatically validated against the user’s Salesforce locale format. On mobile devices, fields of type datetime use native mobile date and time pickers.
  6. Email: Displays an input field for entering an email address. The email pattern is automatically validated.
  7. Geolocation: Displays input fields for entering latitude and longitude in decimal degrees. The latitude field accepts values within -90 and 90, and the longitude field accepts values within -180 and 180.
  8. Lookup: Displays an input field for creating a relationship between two objects, for example, the account associated to a contact record. The lookup type is supported in Lightning Experience only. Mobile lookups are not supported. When used in the mobile app, the lookup type is rendered as an input text field. The Owner, CreatedBy, and LastModifiedBy fields are not supported for lookups.
  9. Name: Displays one or more input fields for setting the name of a record. Input fields can include a single name field or multiple fields. For example, accounts might have a single name while contacts might have a salutation, first name, and last name.
  10. Number: Displays an input field for entering a number and formats it based on the user's locale.
  11. Password: Displays an input field for entering a password. Characters you enter are masked.
  12. Percent: Displays an input field for entering a percentage.
  13. Phone: Displays an input field for entering a phone number.
  14. Picklist and multi-select picklist: Displays a picklist or multi-select picklist. Dependent picklists must be defined in your org before you can use them with lightning:inputField. Both controlling and dependent fields must be included in your component. See the example below.
  15. Text: Displays text input, accepts up to 255 characters.
  16. Text (Encrypted): Displays the encrypted text input for up to 175 characters.
  17. Text Area: Displays multi-line text input for up to 255 characters.
  18. Text Area (Long): Displays multi-line text input for up to 131,072 characters.
  19. Text Area (Rich): Displays rich text input for bold or underline text, lists, and images for up to 131,072 characters including the formatting and HTML tags. Unsupported tags and attributes are removed and only their text content is displayed. For more information on supported tags, see Rich Text Editor in Salesforce Help.
  20. URL: Displays a URL input field which checks for a protocol such as http:// or ftp://

and For second question for input field it follows the meta configuration of field for lightning input we can only set validity by making

<lightning-input required="true" label="input value">
</lightning-input> 

with required attribute.

1
  • 1
    I saw that list of supported fields a few hours after posting. It's a pretty large oversight not to have working time field support. Oh well. I ended up mixing input-fields and just inputs under the record-edit-form. It took some additional logic on the js side (on submit, on error) to get things handled correctly. I'm not happy that when using button type="submit" that field validity is handled internal in the input-fields and not passed to submit handler. So I have to do a manual validity check for the regular input fields in that handler separately. It's not the best user experience IMO.
    – Rick
    Commented Sep 8, 2019 at 18:28
-1

I understand the limitations which is present due to the fact that you have to use the lightning-record-edit-form or lightning-record-form (under the hood LDS fetches SF data so there exist tight coupling between base component UI and service which cannot be changed by developer), but if you need more control over the look and feel then I recommend to use force:recordData to create your form.

I see you are not willing to go the Custom Form/LWC Component route either in that case its best to open a case with salesforce customer support. With Lightning-input-field also there is not much which can be done in this matter. Lightning-input-field and lightning-input are two different base components and Rick's concern is the first one. Second one applies if he is willing to create custom component/form which he is not.

Regards Mitesh

2
  • Why a down vote on my answer? The answer accepted here is actually from same issue - lightning:inputField and time fields
    – Mitesh
    Commented Sep 7, 2019 at 13:02
  • Correct. I wanted to leverage lightning-input-field and lightning-record-edit-form. I wanted an example to for the other DEVs on my team, to be able to easily leverage that with @wire for forms that aren't critical in functionality/appearance/etc (all our other forms are 100% custom built). I ended up doing a mix of regular lightning-input and the field one, all inside the lightning-record-edit-form. I had to build more logic on the js side (for on submit, and on error), but I got it working. It's a shame about the time fields though.
    – Rick
    Commented Sep 8, 2019 at 18:21

Not the answer you're looking for? Browse other questions tagged .