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

Javascript Initialization

Aperta
  • Qualcosa non va?
#220 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
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
javascript, python
Ambito
api

Direzione di ricerca

Inizia individuando l’entry point frag.initialize_js e tracciando il modo in cui l’inizializzazione JavaScript viene attualmente esposta agli XBlocks. Definisci come zero o più parametri compatibili con JSON raggiungono il lato JavaScript senza richiedere templating HTML, CSS o JavaScript. Il lavoro è completato quando l’API accetta le forme di parametro richieste e preserva gli asset statici compatibili con i browser.

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

Descrizione

@pmitros: "It'd be nice if I could pass parameters to frag.initialize_js. I'd suggest these could be JSON objects (so string, dicts, arrays, integers), and I could have anywhere between 0 and infinity of them.

Right now my options for doing this are:

  1. Add templates to my HTML/JS/CSS. This is ugly.
    a. I can no longer develop in browser without running the workbench. It forces my code to couple to workbench. I know I could probably find some way to split this among files where there is a test file and a workbench file, but that kind of sucks.
    b. It forces me to put things inside HTML/CSS/JS files that break the semantics of what those files mean. I have to template in big data blobs in human-readable files.
  2. I can do AJAX, with extra requests.

In addition, in both cases, it's an extra chunk of unnecessary code. I have to do $("#script_tag").text() or make web requests or similar."

@cpennington: "How does it couple you to workbench? Unlike XModules, w/ XBlocks we're advocating that users do their own templating (rather than relying on the runtime for templating). For instance, you could just do native python string interpolation, if that's enough for your needs.

Otherwise, I like the idea."

@pmitros: "If I can keep pure JavaScript, HTML, and CSS in files, I can develop and debug directly in Chrome/Firefox, as per my preference, and I can deploy either to the XBlock, or just upload static files to the web.

The instance I have /any/ kind of templates, be it Python .replace(), Python .format(), mako, etc., the code can only work inside of some kind of server which does that templating. I'm coupled to a more complex development and deployment mechanism. In abstract, I could build a separate server, one for XBlocks and one not to do the templating, or build an independent deployment mechanism, but in practice, that's a lot of work with no benefit (if I need a server, workbench is as good as any and better than most), so I'm left with developing in workbench. Being able to develop and deploy just in-browser is, on the other hand, a big benefit, as is being able to use the same HTML/CSS/JS files for both interactives on static pages as in XBlocks."

Lingua principale
Python
Stelle
470
Fork
231
Merge medio
2g 14h
PR unite (30g)
7

Preparare l'ambiente

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 openedx/XBlock

Tutte le issue di openedx/XBlock

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.