Un bloque de otra actividad al conectarse se desgrisa

[asanzo]

Cuando importás la solución de un desafío distinto, puede pasar que vengan bloques que no son del challenge actual. Eso está bien, y hoy se grisan (lo cual también está bien).

El problema es que al conectar un bloque grisado, vuelve a la normalidad:

• Lo que debería pasar es que aunque se conecte se mantenga gris.
• Si eso no se puede, al menos al apretar ejecutar no sólo debería activarse el chequeo de bloques vacíos sino también refrescar el chequeo de los bloques grises.

[asanzo]

Revisar su sigue o si ya se arregló

[PalumboN]

Sí, sigue pasando.

[looseale]

Hola @asanzo, consulta sobre el issue: hay alguna razón por la que se quieran mantener los bloques de la solución que no apliquen al challenge? Porque si no es necesario mantenerlos se podría hacer un dispose() de esos bloques y borrarlos dejando solo los que apliquen al challenge. Intente aplicar la primera solución (que se mantenga deshabilitado), pero como los bloques del challenge también están deshabilitados por default si están fuera del bloque de ejecución no encontré forma de diferenciarlos. La segunda opción creo que si el aplicable, pero quería confirmar para evitar un rechequeo si no es necesario. Desde ya gracias.

[asanzo]

¡¡ Hola, @looseale !!

La pregunta es ultra válida. El feature de importar los bloques está porque hay algunas actividades (particularmente las del segundo libro de Dibujando Figuras) en las que se espera que reuses soluciones.

Además, hay una similitud estructural entre las soluciones de repetición condicional, y nos ha pasado que hay gente que ha importado soluciones de otros ejercicios para resolverlos. Eso en principio nos parece un enfoque que no queremos desalentar por ahora, porque hace al aprendizaje de programación (y bien que lo re hacemos lxs programadorxs en industria también XD).

Ahora bien, imaginando este último escenario, es importante que aparezcan los bloques (y grisarlos) para saber en qué lugar reemplazar "levantar tuerca" por "comer banana". Es una cuestión didáctica. El dispose los hace desaparecer y nunca sabés dónde estuvieron.

Para deshabilitarlos, eso se hace en el método disableNotAvailableBlocksInWorkspace del service available_blocks_validator.js. Creo que es tan simple como llamar a ese método cuando corresponda.

[asanzo]

(chusmeá un poquito desde dónde se llama ese método)

[rgonzalezt]

Otra forma de resolver esto no es grisando el bloque que no sea propio del ejercicio, sino poder comunicar el error al usuario de forma correcta. Deberíamos analizar este caso con más detenimiento.

[PalumboN]

Holiisssss, pasaba por acá y vi preguntas interesantes. Dejo algunos comentarios que me surgieron :)

Estado actual

Fui a una actividad de Mañic y creé este programa:

Lo guardé y lo abrí en uno de Capy:

• Al cargarlo aparece este cartel advirtiendo que es una solución de otra actividad 👍

  

• Sin embargo, a diferencia del gif que está en la descripción, el bloque que no pertenece a la actividad no tiene ningún warning ni nada 👎

  

• Al ejecutar el programa, el bloque que pertenece (compartido entre ejercicios) se ejecuta bien y el segundo se ejecuta también teniendo como resultado uno similar al que tendría Mañic (en caso de error) 😕

  

Problemas que veo / cosas que me gustaría mejorar

Secuencia de actividades (un caso de uso)

El feature de importar los bloques está porque hay algunas actividades (particularmente las del segundo libro de Dibujando Figuras) en las que se espera que reuses soluciones.

En esos casos donde los ejercicios están diseñados para importar soluciones de otro, salta también el cartel? Por lo que probé, sí. En esos casos estaría bueno que no pase, ya que no sería "un error de usuario" sino una "propuesta del docente".

Feedback estático (origen del issue)

Como feedback me gustaría que los bloques que no pertenecen tengan algo que llame la atención:

• En mi prueba no tiene nada, no lo banco.
• En el gif de la descripción tiene un warning, lo banco.
• El issue propone grisarlo, no lo banco mucho porque ese feedback es para bloques que están tirados por ahí. Básicamente un bloque sin usar y uno de otra actividad se verían igual (a menos que además dejemos el warning), y no banco.
• Se podría jugar con otra cosa, quizá ponerle un highlight rojo o algo así, que diga que se va a romper todo (a diferencia de las cosas que decimos para mejorar la solución).
• Otra opción que tiraron es de directamente eliminar los bloque que no pertenecen a la actividad. Para mí esa es medio border porque estaríamos modificando el programa que se carga y puede generar confusiones. No banco mucho.

Feedback dinámico (qué esperamos que pase?)

Por último, si igual toco ejecutar el programa que tiene bloques que sabemos que no van a andar, qué hacemos?

• Podríamos evitar por completo la ejecución, similar a lo de los bloques vacíos (que también se propuso por acá). Esa sería una opción válida. Habría que ver qué hacer si tenés bloques de otra actividad que no están conectadas al programa principal...

Otra opción es ejecutar el programa, como pasa actualmente. Y acá la pregunta es qué hacemos cuando se ejecuta el bloque de otra actividad:

• Ahora está ejecutando el bloque como si fuera el personaje para el que fue pensado, y tira el error correspondiente al bloque.
• Me pregunto si no queremos otro tipo de error onda yo no sé hacer eso.

Todo depende del nivel de polimorfismo que queramos entre los personajes, y esa parece ser una decisión pedagógica :)

My two cents!

[asanzo]

Estoy absolutamente de acuerdo en absolutamente todo lo que dijo el absoluto Rasta.

¡¡GRACIAS RASTA!!

Creo que en tu mensaje está la especificación de lo que tenemos que hacer. Este issue hay que tenerlo en cuenta cuando estemos migrando los bloques.