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)