[BUG]: Something happens with SketchGroups when returned via a map

[paultag]

Describe the bug

I'm able to return a SketchGroup from a function, but if it's inside an object, it doesn't behave the same as returning it directly.

Steps to Reproduce

fn test = () => {
  return startSketchOn('XY')
    |> startProfileAt([0, 0], %)
    |> line([0, 1], %)
    |> line([1, 0], %)
    |> line([0, -1], %)
    |> close(%)
}


fn test2 = () => {
  return {
    thing: startSketchOn('XY')
      |> startProfileAt([0, 0], %)
      |> line([0, 1], %)
      |> line([1, 0], %)
      |> line([0, -1], %)
      |> close(%)
  }
}

const x = test()

x
  |> extrude(-10, %)

const x2 = test2()

x2.thing
  |> extrude(10, %)

Argument at index 1 was supposed to be type kcl_lib::executor::SketchGroupSet but wasn't

Expected Behavior

I should see two rectanges, one going down, one going up. I only see one going down.

Screenshots and Recordings

Desktop OS

Linux

Browser

Chrome

Version

Version 127.0.6533.88 (Official Build) (64-bit)

Additional Context

No response

[paultag]

[jtran]

I think I know what’s going on here. We move values around (in variables in ProgramMemory, Pipelines, etc.) using the MemoryItem type. When it’s just a SketchGroup, MemoryItem has an enum variant for that. But when it’s an Object, MemoryItem stuffs it in UserVal, which is a JSON value. So the SketchGroup gets serialized to JSON. The data is technically there, and we could jump through hoops to get it out. But I think we really need to stop storing values in JSON #1130 on the Rust side.

[jessfraz]

yeah i agree #1130 is the real fix, i have previously done the hoops and it would be nice to just fix this globally

[jessfraz]

cc @adamchalmers