Build UI Library Available for Extensions

[austincondiff]

We should allow extension developers to use a library of standardized UI components so that we can ensure a consistent visual design throughout CodeEdit and it's extensions.

The following UI components will need to be available for extensions to use for views in the navigator, inspector, and debug areas:

• Stacks
  • [ ] HStack
  • [ ] VStack
  • [ ] ZStack
• [ ] List
  • [ ] Section
    • [ ] SectionHeading
  • [ ] ListItem
  • [ ] TreeListItem
  • [ ] ListItemDetails
• [ ] Grid
• [ ] Menu
  • [ ] MenuItem
• [ ] Button
• [ ] Popover
• Pickers
  • [ ] Segmented/Menu-style Picker (Select)
  • [ ] Color Picker (Swatch)
  • [ ] Date/Time Picker

Possible UI elements (need further elaboration):

• Tabs
• Tab

Note: some of these are standard to SwiftUI however depending on our architecture we may need to expose these through CodeEditKit.

Other considerations:

• We could possibly use this UI library internally.
• If we decide to build a JavaScript API, we'd also need to create a set of React components.

We should also keep in mind what we plan to allow developers to extend. This might include:

• Navigators
• Inspectors
• Debuggers (is that what we want to call these?)
• Previews
• Languages/Grammars (what should this include?)
• Commands
• Formatters
• Validators (places warnings and errors in code)
• Snippets
• Code completions
• Project Templates
• Task Runners (not sure about the accuracy of this name - provide necessary fields to configure tasks for a particular language/framework)

[KaiTheRedNinja]

In my experiment over here, I use the following structures for "primative" ui elements (VStack, HStack, Text, Button):

• Stacks

  {
  "viewType": "vstack", // or hstack
  "content": [/*other json representations of UI elements*/]
  }

• Text

  {
  "viewType": "text",
  "content": "content here"
  }

• Button

  {
  "viewType": "button",
  "onClick": "name of callback function",
  "content": { /*other json representation of a UI element*/ }
  }

All views need a viewType field, which is used on the Swift side to decide which view to render. I use content for what is shown in the view, but it could be renamed for each different kind of content (eg. plaintext, a single view, or multiple views)