Convert Form::textarea to blade component

[marcusmoore]

This PR introduces the <x-input.textarea> blade component and uses it to replace Form::textarea usage in our blade templates.

---

Pages Affected

• Categories
  • https://snipe-it.test/categories/create
  • https://snipe-it.test/categories/1/edit
• Custom Fields
  • https://snipe-it.test/fields/create
  • https://snipe-it.test/fields/1/edit : has to been a list box element
• Settings
  • https://snipe-it.test/admin/branding
  • https://snipe-it.test/admin/settings
  • https://snipe-it.test/admin/ldap
  • https://snipe-it.test/admin/saml

Modals Affected

• Upload file modals like on https://snipe-it.test/hardware/1#files

---

Extracted via copy/paste from #15983.

[what-the-diff]

PR Summary

• Introduction of a New Text Area Component
  This PR focuses on the introduction of a new text area component to the Blade file, simplifying existing codes and making it more reusable for future needs.

• Updated Usage of New Text Area Component
  Replacing the previous Form::textarea with the newly-created <x-input.textarea> component, this update provides greater consistency in multiple files including, but not limited to:

  • 'Edit Fields' section in custom fields
  • EULA text area in category edit form
  • Notes input in file upload modal
  • Custom CSS and footer text inputs in branding settings
  • Default EULA text in general settings
  • LDAP TLS key and cert fields in LDAP settings
  • SAML settings inputs in SAML settings

These changes promote a uniform implementation of the text area component, thus making the platform more synchronized and manageable.

[snipe]

Looks like we have a conflict here, and this is targeted to master

[snipe]

I think I fixed the conflict, but the branch switch is a bit messy - possible for you to rebase or merge down?

[marcusmoore]

I'll take a look.

[snipe]

I am, of course, in the middle of adding textareas to a bunch of forms right now lolsob. I'll put them in as in my PR and then update them to this format once it's targeted to develop and merged.

[snipe]

Looks like Sqlite tests are failing

[marcusmoore]

The sqlite tests are due to a mismatched timestamp. Another run should get them to green.

Now that it is caught up to master I'm not sure how to do the branch change cleanly...

[snipe]

I'm guessing you must have branched off of master to start with, based on the changes (and the version.php).

Please also make sure you are using translation strings for placeholder text.

[snipe]

I hadn't noticed this, but we don't actually use cols, since we let bootstrap handle the width.

[marcusmoore]

The Form::textarea call actually added those in there so the resulting html included it. Should I remove it as an prop in the component?

[snipe]

Probably - it won't matter, since the CSS will override it, but we don't need it. Not urgent tho. The behavior will be the same.

[marcusmoore]

Just did it so I didn't forget about it 😅

https://github.com/snipe/snipe-it/pull/16225

[marcusmoore]

I'm guessing you must have branched off of master to start with, based on the changes (and the version.php).

Those changes came along with the "catch up" merge from what I can tell. I think if the order was flipped and the target branch was changed to develop then caught up it would've worked out cleaner.

Please also make sure you are using translation strings for placeholder text.

My intention was to do the replacements as simply as possible and avoid extracting new translation entries for the untranslated strings I came across. I can open a follow up PR extracting those though.

[snipe]

My intention was to do the replacements as simply as possible and avoid extracting new translation entries for the untranslated strings I came across. I can open a follow up PR extracting those though.

I get it, but we always end up missing stuff. Hang on for adding those, since I'm creating a new array for placeholders in general - you can add to that.