materializecss / materialize

Materialize, a web framework based on Material Design

Home Page:https://materializeweb.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Missconception while adding new chips [Bug]:

sashnone opened this issue · comments

Before submitting...

Context

In a case of ADDING new Chips you assign "Input text" to an ID of new chip. Wich is breaking logick of 2.0.0 chip data structure

Current Behavior

It's more logical make this.addChip({ id: null, text: this._input.value });//INSTEAD this.addChip({ id: this._input.value }); LINE 2733

Expected behavior

while adding new chips i expect to get the same structure of chips data similar to rest of framework

Possible Solutions or Causes

as I mentioned this.addChip({ id: null, text: this._input.value });//INSTEAD this.addChip({ id: this._input.value }); LINE 2733
also fix some functions checking validity of chips which is not allowed chip without id. It is possiblw while chip didnt get an id from database

Steps to reproduce

No response

Your Environment

  • Version used: v2.0.3-alpha
    • Browser Name and version: FIREFOX 120.1
  • Operating System and version (desktop or mobile): Windows 11 desktop
    • Additional information you want to tell us: there few more bugs i found, but this was last one that overcome my pation to not tell you...

English is not my native language, sorry

I dont understand where a bug is. I looked into the code and it is clear what you can do. addChip(chip: ChipData)
Chips Documentation

As far as I see, you are not doing any validation step between input-field and addChip. Instead the input-data is directly connected to the addChip() Method. This could cause many issues and is not a very good practice. It would make sense to have an additional validation step between, before putting data to the addChip Method. In this step you can check if the input-data is null for example and then not add a chip.

For now it is allowed to put any data for the id. The validation has to be done externally/manually because we dont know if someone wants to use numbers as Ids too or any other datatype. I intentionally left this open and flexible, because the validation and search functions should be customizeable and cover many usecases.

A potential solution I could live with, can be:

Lock the id-property of ChipData to string only and validate for that.

But this is a feature then. Any suggestions?

It would be awesome if you could provide some additional test-cases for this types of scenarios.
I would gladly add them to the project. Thanks for taking the time and finding some issues. Any help is welcome!

Hi! I am very grateful for your reply. The fact is that I am making a tag system where I allow the user to add new tags, in a way as indicated in the documentation. But the fact is that I noticed that when adding a new tag, information is transferred from the input field to it, but not to the paramert TEXT, but to the ID parameter, (this.addChip({ id: this._input.value }); LINE 2733) and when this information is sent to the backend, logic is violated. Because the entered value is expected in the TEXT field. In this case, the ID field must be NULL, because this "Chip" does not yet have its own ID, and it must be assigned by the backend.

commented

@sashnone It seems like you need to make the data from the chip widget conform to your backend's expected format before sending it. I've been using the variation with class="chips chips-placeholder" for similar tag functionality, and have had no issues. When I populate the tag on page render, I get the info from the backend (a list of strings) and convert it to chip widget's expected structure like so: tags.map(t => ({ id: t })). I do the opposite when I send tag data to the backend: chip.chipsData.map(v => v.id.trim()) where chip is the widget instance. This goes from a list of objects to a list of strings.