Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
#98 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Refactorisation
Clarté
Plutôt claire
Activité
À l'abandon
Domaine
frontend

Piste de recherche

Commencez par retracer le datatype Spot existant et le flux actuel d’amélioration des textareas décrit dans l’issue. Comparez la manière dont les brouillons sont identifiés et restaurés avec le schéma URL/timestamp proposé ; le travail est terminé lorsque le projet dispose d’un modèle générique convenu pour préserver et faire correspondre les brouillons de plusieurs textareas.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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
Langage dominant
HTML
Étoiles
58
Forks
0
Aucune PR mergée en 30 j

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de diffplug/gitcasso

Toutes les issues de diffplug/gitcasso

Issues similaires

Plus d'issues Web Dev

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.