Hallo pl,
ich persönlich halte die Idee, ein Attribut eines Datenobjekts nach einem Löschvorgang neu zu vergeben, nicht für gut. Eine ID ist eine ID und bleibt eine ID. Wenn ein neu angelegter User eine ID bekommen hat, dann sollte er die auch behalten. Und er sollte sie von hinzu() bekommen, nicht von render(). Das verletzt das SoC Prinzip.
Ein Lösch-Button sollte
- nicht die ID des Elements anzeigen, sondern ein Mülleimer-Symbol oder ein X. Man weiß ja sonst gar nicht was er tut. Ein Edit-Formular anzeigen, etwa?
- die zu löschende ID als value-Attribut enthalten
- type="button" haben wenn eine reine SPA-Funktion gewollt ist. Ohne type="button" ist es type="submit", d.h. ein <form> (was Du nicht hast) würde an den Server geschickt und ein korrekter Event-Handler müsste das verhindern. Das wäre eine Fallback-Strategie für deaktiviertes JavaScript
- in Leserichtung als letztes kommen (meine ich jedenfalls). Die Insert-Zeile könnte an dieser Stelle den "Speichern" Button bekommen (ggf. mit einem Häkchen drin).
- nicht einzeln mit onclick attributiert sein, statt dessen sollte man unobtrusiv mit addEventListener einen click-Handler auf die table legen und die Klicks schön hochblubbern lassen. Bei Eintreffen schnell event.target abfragen ob es ein Button ist und dann den value auswerten.
Ein div#out um die table ist für deine Darstellung auch nicht nötig, die id kannst Du auf die Table legen wenn Du sie brauchst. Wenn's auf Vorrat für weitere UI Elemente ist, ok, dann will ich nichts gesagt haben.
Die Vorbelegung der Eingabefelder mit "Name" und "Vorname" finde ich Käse. Nimm lieber ein placeholder-Attribut. Das reicht aber nicht als Beschriftung; ich denke, ein sehbehinderter User mit Screenreader bekommt die Eingabefelder mit den Table-Headern (welche vielleicht besser in einem thead stehen sollten) nicht zusammen. Eventuell wären visuell versteckte Labels nötig, damit Accessibility gewährleistet ist.
Rolf
sumpsi - posui - clusi