MCP Server Part 1: framework utilities and types

[KoolADE85]

Summary

For schema generation:

• Make Dash Component class compatible with Pydantic
• Move NumberType definition out from individual components into a generic place where the type can be introspected (and also made compatible with Pydantic)
• Add stronger type definitions for callbacks (CallbackDispatchBody, CallbackDispatchResponse)

Utilities

• Add framework utilities for traversing layouts and inspecting Dash components (dash/layout.py)
• Add pydantic>=2.10 to dependencies

Manual testing

There isn't any visible feature, but you can try out the layout traversal and pydantic type exposure by hand:

from dash import Dash, html, dcc
app = Dash(__name__)
app.layout = html.Div([
    html.Label("Name:", htmlFor="name-input"),
    " ",
    dcc.Input(id="name-input", value="World"),
    html.Div([html.Span(id="deep-child", children="deep text")], id="inner"),
], id="root")

with app.server.app_context():
    from dash.layout import traverse, find_component, extract_text
    for comp, ancestors in traverse(app.get_layout()):
        indent = "  " * len(ancestors)
        print(f"{indent}{type(comp).__name__} id={getattr(comp, 'id', None)}")

    from pydantic import TypeAdapter
    from dash.development.base_component import Component
    print(TypeAdapter(Component).json_schema())

[github-actions]

Thank you for your contribution to Dash! 🎉

This PR is exempt from requiring a linked issue due to its labels.

[T4rk1n]

This import doesn't exist on previous versions of dash, to maintain backward compatibility, types are created on the generated file.

[KoolADE85]

I think I understand the backwards-compatiblity issue here, but tell me if I'm missing something:

• 3rd party components generated with this change would become incompatible with dash<=4.1.0.
• Our own dcc/html components are tied to the framework version, so there is no compatibility issue internally.

What do you think about "transitioning" the NumberType into the framework by including a conditional import in the generated components:

try:
    from dash.types import NumberType
except ImportError:
    NumberType = typing.Union[typing.SupportsFloat, typing.SupportsInt, typing.SupportsComplex]

This would maintain backwards compatibility while also giving us a type that we can change in the framework going forward.

[T4rk1n]

Yea that could work.

[KoolADE85]

OK great - I pushed up that change.

[T4rk1n]

Not sure about naming this file layout as this might confuse users with the import. Also common pattern is the user have a layout file/variable/function and importing this would need to be aliased in those case.

If this is not intended to be used by the dash app developer, then maybe rename to _layout, otherwise maybe something like layout_tools or layout_utils would be more explicit.

[KoolADE85]

Good call - I renamed this to _layout_utils.py.

[T4rk1n]

But now there's two import, since both definitions are types I think the else is redundant.

[KoolADE85]

Unfortunately there is a quirk here for pyright: the type checker is not satisfied with the try/except style of import and the Typing Tests fail.
I re-wrote this more compactly, but as far as I can tell we need to use the TYPE_CHECKING constant in order to satisfy pyright.