Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Javascript Initialization

Abierto
  • ¿Algo no está bien?
#220 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
javascript, python
Área
api

Línea de trabajo

Comienza localizando el punto de entrada frag.initialize_js y siguiendo cómo se expone actualmente la inicialización de JavaScript a XBlocks. Define cómo llegan cero o más parámetros compatibles con JSON al lado de JavaScript sin requerir plantillas de HTML, CSS o JavaScript. Se considera terminado cuando la API acepta las formas de parámetros solicitadas y conserva los recursos estáticos compatibles con los navegadores.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

@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."

Lenguaje dominante
Python
Estrellas
470
Forks
231
Merge medio
2 d 14 h
PR fusionados (30 d)
7

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de openedx/XBlock

Todos los issues de openedx/XBlock

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.