Nested steps for tools etc.

[minhduc0711]

Describe the bug
Version 1.1.300 introduced a new UI design to display intermediate steps, but the nested steps are no longer displayed in a nested manner.

To Reproduce
Run this example

import chainlit as cl


@cl.step(type="tool")
async def parent_step():
    await child_step()
    return "Parent step output"


@cl.step(type="tool")
async def child_step():
    return "Child step output"


@cl.on_chat_start
async def main():
    await parent_step()

Expected behavior
The child step should be indented to indicate that it is nested inside the parent step.

Screenshots

Desktop (please complete the following information):

• OS: Windows
• Browser: Firefox
• Version: 126.0.1

[hayescode]

yes this is by design. Why? I don't know. My users overwhelmingly miss the old tool UI. They do like the starters though (albeit they miss the markdown homescreen details).

[GeorgSatyros]

Not sure what the benefit was in completely removing existing, core functionality but it did a number to our application..
We may need to roll back and fork, even though we really like most other changes introduced.

[pchalasani]

Not sure what the benefit was in completely removing existing, core functionality but it did a number to our application..

Indeed, the new release completely breaks the demo examples on Langroid, a Multi-Agent LLM framework.

Even version 1.1.202 has un-intuitive design choices that seem to be based on a limiting mental model of what "steps" and "sub-steps" might constitute. Steps could be so-called "chain-of-thought", but that's just one possibility. Steps could also be an Agent delegating to a sub-agent, which Langroid supports.

E.g. when step B has parent_id pointing to step A, I expect the output of B to not only nest one level under A, but also the output of B should be displayed in chronologically correct order. E.g. in case B delegates to C, the C outputs should come after B's output. E.g. if I run the code below with 1.1.202

import chainlit as cl


@cl.on_chat_start
async def on_chat_start():
    a_step = cl.Step(name="A", type="text")
    a_step.output = "asking B"
    await a_step.send()

    b_step = cl.Step(
        name="B",
        parent_id=a_step.id,
        type="text",
    )
    b_step.output = "asking C"
    await b_step.send()

    c_step = cl.Step(
        name="C",
        parent_id=b_step.id,
        type="text",
    )
    c_step.output = "C answered!"
    await c_step.send()

I get this non-sensical ordering of outputs and steps (the nesting is correct though):

For example "asking B" should be displayed right under A, before the B step, etc.

If I switch to the latest release, things are broken in a new way, i.e. non-tool steps are no longer displayed at all. But even if I change those step types to "tool" just to get them displayed, it seems like the chronological order is respected (good), but nesting no longer respects parent_id pointers:

IMO two things need to be made configurable, and not baken-in to fit someone's specific mental model of what steps and sub-steps might mean:

• whether to display non-tool step types or not
• whether to respect parent_id when nesting steps

Currently the design choices seem to be based on a failry limited view of steps and sub-steps, and completely ignore a multi-agent viewpoint. I've heard arguments such as:

• "end users don't want to see sub-steps to arbitrary levels deep" -- well, that depends on their sophistication and the specific use-case
• "sub-agent hand-offs should be implemented as tools, then you can see those" -- but not everyone wants to implement hand-offs as tools.

[jdb78]

@willydouhard , are you looking into changing this back / making it configurable or is this not on the roadmap?

[hayescode]

Adding our new lord and savior @dokterbob

[marketneutral]

Also very frustrated by this. I see old examples of chainlit with screenshots in the Cookbook or in Medium and they look so beautiful. The current UI is a huge step backwards. Chainlit is an incredible project that we all love. Please consider changing the UI back.

[dokterbob]

Hey all, what's necessary to bring this back? How can we organise to move towards a PR? What skills are required etc. etc. Let's try and be productive on this.

But please be aware, my priorities (at this moment) are:

1. Fostering community contributions
2. Furthering security, stability and reliability
3. Reducing (a huge amount of) technical depth.

So I won't be implementing this feature for you, but will happily do whatever else I can to move it forward. From my perspective, it's a new feature. I know y'all like to get heard -- but it's not helping us resolve things!

Perhaps we could:

• Rename this issue.
• Spec what the ideal UX would be like (that means we don't need to cling to the past!)
• Spec exactly what changes in the backend and frontend are required to make that happen
• Draw out a roadmap
• Create bite-sized issues and PR's (preferably split in specific expertise, like backend, frontend, design) to get us there

What do y'all think?