feat: 143-text-input-element refactore code

[rpt-rfoxy]

Pull request checklist

• Create component TextInput

Detail as per issue below (required):
as figma refenrece here Figma

schreenshoot

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for b8327541	✅ 72.92%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (b832754)	Report Missing	Report Missing	Report Missing
Head commit (9ac8f98)	4288	3868	90.21%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#329)	48	35	72.92%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[kurtdoherty]

question: was there a solution design or discussion for form controls that I've missed?

Forms are complex, nuanced and have a high-cost of change for consumers, so I don't think we should be implementing individual form controls until we've decided how we expect forms to be implemented at a high-level first.

[rpt-rfoxy]

question: was there a solution design or discussion for form controls that I've missed?

Forms are complex, nuanced and have a high-cost of change for consumers, so I don't think we should be implementing individual form controls until we've decided how we expect forms to be implemented at a high-level first.

hi @kurtdoherty the ticket discussion is here here, this component has dependent to icons, so i create the actual code to see the changes

[kurtdoherty]

Okay, well I don't think we've investigated forms enough to really get started on any of the individual controls yet. Without understanding how we expect products to facilitate form validation, submission, type safety and so on, any work on individual controls (like a text input) will be making prop interface decisions in the dark.

[rpt-rfoxy]

Okay, well I don't think we've investigated forms enough to really get started on any of the individual controls yet. Without understanding how we expect products to facilitate form validation, submission, type safety and so on, any work on individual controls (like a text input) will be making prop interface decisions in the dark.

hi @kurtdoherty
questions: are we gonna handle form validation and type safety inside input component? since i know consumer will use third party form validation like yup or seomething else, and handle the form submition using react hook form

[kurtdoherty]

questions: are we gonna handle form validation and type safety inside input component? since i know consumer will use third party form validation like yup or seomething else, and handle the form submition using react hook form

Not sure at this stage. React 19 introduces some new form-related features that we need to investigate and assess; they may reduce the need to rely on react-hook-form or formik for form state management. The DOM provides all the basic validation we need too, so we may only want to reach for something like Yup or Zod for more complex validation scenarios. All of this uncertainty is why we need to move cautiously.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for 80da58e1	✅ 72.92%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (80da58e)	Report Missing	Report Missing	Report Missing
Head commit (f9f19be)	4457	4050	90.87%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#329)	48	35	72.92%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[rpt-rfoxy]

questions: are we gonna handle form validation and type safety inside input component? since i know consumer will use third party form validation like yup or seomething else, and handle the form submition using react hook form

Not sure at this stage. React 19 introduces some new form-related features that we need to investigate and assess; they may reduce the need to rely on react-hook-form or formik for form state management. The DOM provides all the basic validation we need too, so we may only want to reach for something like Yup or Zod for more complex validation scenarios. All of this uncertainty is why we need to move cautiously.

hi @kurtdoherty , thanks or the details,
question : about waithing react 19 implementation, should we label it as 'on hold' ? or the ticket i mean.

[kurtdoherty]

Yes, we should mark this as "on hold" for now. I'm planning to get some high-level decisions made to unblock this work before I go on leave at the end of next week. Those decisions should allow you to at least progress some of the text input work you've proposed here.

[adrian-reapit]

FYI, we use react hook form and validation at the component level to avoid yup and display errors in the error label component with an error summary view at the top. Could just update the visuals and leave react 19 implications to v6

[adrian-reapit]

assume this will move to a shared error text component for wider use, also getIconSize can be shared

[rpt-rfoxy]

hi @adrian-reapit & @ksolanki7 thanks for the feedback,

question 1 : should we create new ticket for error text component or we can use the same ticket and split it by PR?

question 2: about the error text component since its used only for input should we create sub directory ? for example:

Component/
  ├── inputs/
  │   ├── text-input/
  │   ├── date-input/
  │   ├── file-input/
  │   ├── error-text/
  │   ├── input-utils/
  │   │   ├── get-icon-size.ts

or just keep it in different folder like this?:

Component/
  ├── another-component/
  ├── text-input/
  ├── date-input/
  ├── file-input/
  ├── error-text/
  ├── input-utils/

question 3:

since the render structure is like this, is it good enough? or you guys have any feedback ?

Notes: i will create new POC or the text-input, i have new idea about the prefix and suffix, i'll update it after this

[adrian-reapit]

sorry for delay. there is a big plan missing for forms but we should be able to make some of the low level components. i have asked about it on figma

[rpt-rfoxy]

ErrorText Component Design Document

hi @ksolanki7 & @adrian-reapit

Overview

The ErrorText component is a simple utility designed to conditionally display error messages in a styled format. It ensures errors are presented clearly while maintaining flexibility in size and display behavior.

---

Component API

Props

Prop	Type	Default	Description
isError	boolean	false	Controls whether the error text should be rendered
size	ElSizesEnum	"small"	Defines the text size; "large" defaults to "medium"
children	React.ReactNode	null	The error message content to be displayed

---

Key Features

• Conditional Rendering: The component only renders if isError is true and children is provided.
• Size Handling: If size is set to "large", it defaults internally to "medium", preventing excessive text scaling.
• Styling: Uses ElErrorText for consistent error styling across the application.

---

Code Concept

To see all example implementations, please check this POC.

---

Usage Examples

Basic Error Message

<ErrorText isError={true}>This is an error message.</ErrorText>

[rpt-rfoxy]

hi @kurtdoherty & @adrian-reapit

i just move the POC link to new sandbox since idk its wont update from my github repository
here the new POC link

please get access first to workspace : link to get request access here

1. POC FormControl here
2. POC Input here

please let me know if the code still doesnt work

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for 80da58e1	✅ 100.00%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (80da58e)	Report Missing	Report Missing	Report Missing
Head commit (ff9dac4)	4187	3944	94.20%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#329)	26	26	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[adrian-reapit]

you don't actually need these name params, this one is wrong but if you delete it then Storybook will use the variable name to create a label