WiP: Prototype generic lo blocks module

[bradley-erickson]

No description provided.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a72d5123a9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Use supported q.keys parameters to avoid TypeError

The q.keys call here passes scope_fields, but the KEYS handler (hack_handle_keys in learning_observer/communication_protocol/executor.py) only accepts STUDENTS, STUDENTS_path, RESOURCES, and RESOURCES_path. When this DAG executes, dispatch_node calls the handler with **node, so the unexpected scope_fields keyword raises a TypeError and the module’s exports never resolve. Use the supported STUDENTS/RESOURCES parameters (as in other modules) or update the handler to accept scope_fields before shipping this module.

Useful? React with 👍 / 👎.

[pmitros]

I have very mixed -- mostly negative -- feelings about merging his PR -- but positive feelings about leaving it open for a while for discussion. It's actually quite interesting to see. It's a very nice proof-of-concept / prototype.

However, before merge, there is a broad range of issues, from:

1. defining time-on-task (see <Collapsible> and similar blocks); to
2. changing event formats (the current ones are interim, and having downstream code rely on them locks us in); to
3. integration with node reducers

Those would need to be discussed and explored.

It is helpful to see some of the abstractions in place and how pieces fit together. We'll want something on both sides of the fence, though, before connecting.

[bradley-erickson]

I agree. This is mostly an exploration of how LO Blocks might integrate into the broader ecosystem.
I haven't pushed the following, but I created a simple dashboard based on the reducers.

[pmitros]

Interesting.

Seeing the dashboard -- in my mind -- opened up an even bigger can of worms:

• The look-and-feel is completely inconsistent with lo-blocks. Indeed, the look-and-feel within lo-blocks is often inconsistent, but this is quite far from any of them. I'm not sure the places this is a bug versus a feature.
• lo-blocks, at the current stage, has no real structure or design for CSS or theming. Having two different theming systems is worse than having one good one.
• I'm still trying to reconcile, in my head, the demands of dash versus react-redux, both of which we build on heavily, both of which use react, but both of which have very different, and likely incompatible, state management.

Nothing here is immediate, but thought I'd leave the thoughts in the PR as a reminder later.

[bradley-erickson]

Providing more context.

The dashboard here is just a prototype built using a new Nextjs application with our websocket hook to fetch and manage data from the communication protocol. A static version of this app could be built and served via the LO Blocks module in this PR.

[bradley-erickson]

Depends on olxhub/lo-blocks#164