Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

multi-textarea data model keyed on (url, timestamp)

Aperta
#98 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Ambito
frontend

Direzione di ricerca

Inizia tracciando il datatype Spot esistente e il flusso attuale di miglioramento delle textarea descritto nell’issue. Confronta il modo in cui le bozze vengono identificate e ripristinate con lo schema URL/timestamp proposto; il lavoro è completato quando il progetto dispone di un modello generico concordato per preservare e associare le bozze di più textarea.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

As the code stands, there is a Spot datatype. It represents the abstract concept of where a single textarea is. e.g.

  • appending the 2nd comment on issue 4
  • appending the 3rd comment on issue 4
  • pros: we have enough data to recreate the draft completely in the browser, and also enough data to tell if it was submitted or not
  • cons:
    • a lot of manual work for each place that we handle
    • ambiguity around things like the issues/new url. You might have multiple unsubmitted drafts in progress, they don't have server-side IDs yet, what should their spot be? Inevitably it gets tied to the time that the tab happened to open, in which case why bother with the complexity of defining the "abstract place where a comment is" if you end up just doing timestamp, URL pairs?

This approach really falls down for complex multi-form things, such as this:

Image

It would be really painful to lose the drafts in those textboxes, but it's also impossible to make a spot for each textfield in every issue/PR template that might be out there.

Another approach is this:

  • anytime a textarea gets added or removed, trigger a refractory state that waits until there's been no changes for 500ms
  • when that refactory period times out (the textareas have settled), the Spot is defined as:
    • primary key: (url, timestamp)
    • schema: list of textareas and their labels, as best we can tell in a generic way
    • title and icon: pulled from the tab by default
  • cons: most of the time, this is not enough data to reopen the tab for the user
  • pros:
    • if the user has opened a tab manually, we can find which saved drafts fit that schema
    • textareas can be enhanced by default, versus right now where they are enhanced only iff we have built an enhancer for that specific box
Lingua principale
HTML
Stelle
58
Fork
0
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di diffplug/gitcasso

Tutte le issue di diffplug/gitcasso

Issue simili

Altre issue su Web Dev

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.