• Add prop name to shouldComponentUpdate

Yeah we definitely need to hide some of these files!

• Add a test for a composite, add package cache so the tests pass

• Add a test for a composite, add package cache so the tests pass

Hmm, this is /sorta/ incorporated into the snapshot tests, but I think we could definitely create some tests around dagre and this overall layout logic. Actually, we may be able to render out SVGs of given DAGs and then compare the SVGs, which would allow you to see WHAT changed when the code is modified / broken (I think otherwise this is just going to be comparing 200kb of JSON full of numbers and they'll just get updated blindly.) Will see if I can set this up today.

Thanks for the comments—will get these addressed tomorrow,

• Fix up comments

• Update snapshot tests

Rebase

This looks great! This approach definitely seems more flexible.

Going to approve with comments, because I'm not certain that my suggested fix will work. If it doesn't, this seems like a good solution.

Looks good! Thanks for making all these fixes.

Looks good to me! I think since we're blowing away and re-creating the cache now when the node set changes, we don't need the custom key mapping (you're correct that it was allowing you to filter the list without recomputing the height of the rows).

Looks good to me! Definitely odd that the autogenerated classnames changed but that seems consistent with my experience 😅

This looks great! Thanks for slogging through this. Made a few comments inline but nothing blocking.

Looks good to me!

👏 Glad to get these out of there!

Looks great! Nice to have this as an option!

• Put input / output names in the label column
• Use typecheck metadata rather than valueRepl (there appears to be none yet)
• Improved metadata table layout
• Fix truncation bug and placement of “read entire message” text
• Displaying IO types in the structured logs, filtering by step type
• Switch to using virtualized list instead of grid, since we do not want all grid features
• Add draggable headers and switch to react-virtualized list component
• Add timestamp heading, adjust styles and column names
• Rebase

Doesn't seem like the buildkite errors above are relevant to this diff, not sure what's going on with the python tests.

Updated screenshot above!

• Displaying IO types in the structured logs, filtering by step type
• Switch to using virtualized list instead of grid, since we do not want all grid features
• Add draggable headers and switch to react-virtualized list component

This should address 1-3 (table styling is more apparent and does not have headers, entire log view now has headers and the dividers can be dragged left/right to adjust column widths. sizing is saved between page loads. The input/output types are displayed in the standard blue) You can also now filter by node type by typing type:expectation or `type: step start, etc. (It just does a partial string match against the event graphQL typenames for now)

• Fix truncation bug and placement of “read entire message” text
• Update failing snapshot tests

Hey folks! Here's are a few screenshots of the latest changes. (Note the new table UI for the metadata entries)

• Put input / output names in the label column
• Use typecheck metadata rather than valueRepl (there appears to be none yet)

• Remove unused types file

• Use the “Repeat” icon for re-execution

Looks good to me! Super weird this happened. (Also separately, it seems like calling a node module fs shouldn't be allowed...)

This looks great! I like that this is generic and that we're also getting value type data from the backend (paths, json, etc.) so we don't have to do any guesswork when it comes to presenting the values. Good stuff!

• Fix padding when the pipeline is selected in the sidebar
• Update the snapshot tests

Looks good to me! I guess we may want to think about whether handleID is still the best word for this. Implementation aside, it seems like solids could have a unique key or id, or if we want to formalize the dot-notation used for them, we could call it a path.

Looks good to me! One minor nit is that a few months ago generate-types started to require that it is run inside the dagster venv. I wonder if there's a super easy way to bail / alert the user if they run generate-types outside the env that will run the python script happily? Right now it blows up in a bit of a cryptic way:

• Remove unneeded file modified every time generate-types runs
• Generate types using Python 3.7 to match BuildKite behavior

• Mark that @types/color is a devDependency
• Switch from indexOf + length to split+pop
• Add ability to double click out of a composite solid by clicking the dark gray background
• Finally have a good solution for animation—CSS rect transition + react keys
• Use the solid tags area to display an “Expand” button
• Slow down the animation a bit
• Click solid before expanding it to prepare the initial animation state
• Move the label on the parent solid container inside to prevent rect bounds from shifting when you zoom
• Looks like BuildKite wants types rebuilt
• Remove unneeded file modified every time generate-types runs

• Remove unneeded file modified every time generate-types runs

• Looks like BuildKite wants types rebuilt

• Slow down the animation a bit
• Click solid before expanding it to prepare the initial animation state
• Move the label on the parent solid container inside to prevent rect bounds from shifting when you zoom

• Switch from indexOf + length to split+pop
• Add ability to double click out of a composite solid by clicking the dark gray background
• Finally have a good solution for animation—CSS rect transition + react keys
• Use the solid tags area to display an “Expand” button

This looks great. I think making this a top level GraphQL query that requires the execution selector makes it more clear that the environment is dependent on the solid subset. I think this is also a nice step toward lowering the systems dependence on the idea of a pipeline. (In case we want to allow any composite solid to be an addressable unit of execution one day, etc.)

Hey folks! Sounds good—we are very far from being able to animate this transition, but I think we can hack something together that communicates what you're looking for. In terms of the zooming in I agree it's a lot of clicks, but I think it's worth considering how often the user will actually want to look inside the solids. I figured this was something you'd do infrequently, and clicking around and having it "jump" inside what you were looking at would actually be more annoying. Regardless, should be easy to come up with something else. There's also an "Expand" button in the sidebar, and we could just put an explicit button in the DAG view as well.

• Mark that @types/color is a devDependency

This looks great to me! Nice visual improvement. It's definitely less generic if we break down "display events" into materializations + expectations and pass those two categories in explicitly, but that does allow for a more customized presentation of each type. I think an alternative would be to allow for display events to have children and do the disclosure triangles in a super generic way, but given that these are probably the two major categories it seems fine to just handle each one.

Looks great! Simple enough 👍

Looks good to me!