Skip to content

Conversation

PerezIgnacio
Copy link

No description provided.

@PerezIgnacio PerezIgnacio force-pushed the add-workflow-rendering branch from 8dcb2d7 to 730e27b Compare October 2, 2025 21:19
chat.ask(input)
end

def to_mermaid
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for now I'm ok, but I'd like to have any diagraming code completely decoupled from the main code. Something like Mars::UI::Renderer.new(workflow).to_mermaid. WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean decoupled in a way that it could actually live on its own in a different gem, but Mars don't really need to care about the rendering part (now is mermaid, but we could have multiple different renderers)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I liked this approach because we could use polymorphism to keep it easy to extend to new objects (each component only needs to know how to render itself), so adding a new component requires just implementing the interface.

That being said, I agree that this is a separate concern and could live in a different layer, possibly different gem, since it's not the core logic and so the objects shouldn't be coupled to it. Let me think of something more aligned to this separation while still keeping the extensibility.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a good example (see how visualize_packs is separate from packs)
image

I'm not saying to have separate gems (it's not worth it for now) but if we can have clear boundaries from the beginning then that could be helpful.

Regarding the solution maybe we can still benefit from this polymorphic solution without having to couple things, for example doing something like:

module Mars
  class Agent
    # core logic
  end
end

module Mars
  module UI
    module Agent
      def to_mermaid
        "#{sanitized_name}[\"#{name}\"]"
      end
    end
  end
end

# Dynamically inject in `lib/mars.rb`
Mars::Agent.include(Mars::UI::Agent)

In the future we may also allow to configure turning on/off the UI module, or changing it for a different UI module for example?

WDYT?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good, I will try something like that.

Comment on lines 22 to 24
def can_end_workflow?
true
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm why only agents can end workflows?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The start workflow can end on a gate for example, here it branches out to another component but doesn't end the main flow. However, it ends if the last node is an agent instead. Later on, I think aggregators could also indicate that the flow ended.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure I'm following. I don't really see the value of this method

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants