This patch adds support for radicle-planning-boards. The Board is hosted on a separate instance, and is embedded in the radicle-interface as an iframe.
Added a new “board” project page, where I have put all radicle-planning-boards related logic. In general, I tried to keep changes outside this file to a minimum, however to add the new page I had to touch a few files. Not sure if there’s a less invasive way to do this I missed. I would be happy to hear feedback on this.
What the Board page does
- Renders an iframe with the radicle-planning-boards url (found in config.json)
- Passes some initial information to the iframe through the url (theme, origin, whether the user is a delegate)
- Establishes two-way communication with the radicle-planning-boards iframe through the postMessage API, and shares the auth token and theme
Integration
Links to the page
The design provided by Daniel suggest adding tabs on the Issues page header to switch between the Issues and the Board page. I have elected not to do this, and instead added links to the sidebar (and bottom bar on mobile). Here’s my reasoning:
- As mentioned previously, I tried to keep interference with the existing code to a minimum. Adding tabs to the Issues page header requires modifying the Issues page, which adds yet another point of contact to maintain in the future
- In the future, the Board could also show patches as well as issues in each column, which would make it a separate entity from the Issues page
- I think the sidebar can serve as a good place for “plugins” like the Board to hook into
Config
I updated the config schema to accept a new plugins key where config for plugins can be added.
The board accepts the following configuration:
enabled- Toggles the plugin on and offorigin- The origin of the radicle-planning-boards instance
Example:
{
"plugins": {
"radiclePlanningBoards": {
"enabled": true,
"origin": "https://radicle-planning-boards.radicle.xyz"
}
}
}
Happy to change the specifics here based on feedback.
Running radicle-planning-boards locally
- Clone the repo
- Update
radicleInterfaceOrigininconstants/config.tstohttp://localhost:3000 - Install the dependencies (
pnpm install) - Start the dev server on a different port than radicle-interface (
pnpm dev --port 4000) - In radicle-interface, add the
originin the config tohttp://localhost:4000and setenabledto true (as shown above) - Start radicle-interface
This patch adds support for radicle-planning-boards. The Board is hosted on a separate instance, and is embedded in the radicle-interface as an iframe.
Added a new “board” project page, where I have put all radicle-planning-boards related logic. In general, I tried to keep changes outside this file to a minimum, however to add the new page I had to touch a few files. Not sure if there’s a less invasive way to do this I missed. I would be happy to hear feedback on this.
What the Board page does
- Renders an iframe with the radicle-planning-boards url (found in config.json)
- Passes some initial information to the iframe through the url (theme, origin, whether the user is a delegate)
- Establishes two-way communication with the radicle-planning-boards iframe through the postMessage API, and shares the auth token and theme
Integration
Links to the page
The design provided by Daniel suggest adding tabs on the Issues page header to switch between the Issues and the Board page. I have elected not to do this, and instead added links to the sidebar (and bottom bar on mobile). Here’s my reasoning:
- As mentioned previously, I tried to keep interference with the existing code to a minimum. Adding tabs to the Issues page header requires modifying the Issues page, which adds yet another point of contact to maintain in the future
- In the future, the Board could also show patches as well as issues in each column, which would make it a separate entity from the Issues page
- I think the sidebar can serve as a good place for “plugins” like the Board to hook into
Config
I updated the config schema to accept a new plugins key where config for plugins can be added.
The board accepts the following configuration:
enabled- Toggles the plugin on and offorigin- The origin of the radicle-planning-boards instance
Example:
{
"plugins": {
"radiclePlanningBoards": {
"enabled": true,
"origin": "https://radicle-planning-boards.radicle.xyz"
}
}
}
Happy to change the specifics here based on feedback.
Running radicle-planning-boards locally
- Clone the repo
- Update
radicleInterfaceOrigininconstants/config.tstohttp://localhost:3000 - Install the dependencies (
pnpm install) - Start the dev server on a different port than radicle-interface (
pnpm dev --port 4000) - In radicle-interface, add the
originin the config tohttp://localhost:4000and setenabledto true (as shown above) - Start radicle-interface
looks neat! i think its a good idea to have a ‘plugins’ section and keep it independent of the rest of the UI
- if we go the plugin-way, i believe Rudolfs has some alternative ideas
we could separate it from main navigation though, and add a section title so it’s clear its a different thing, like so:
and here’s an icon you could use - lmk what you think, happy to come up with alternatives
<svg width="16" height="16" viewBox="0 0 16 16" fill="none" xmlns="http://www.w3.org/2000/svg">
<path fill-rule="evenodd" clip-rule="evenodd" d="M14 13L14 3L12 3L12 13L14 13ZM15 3C15 2.44772 14.5523 2 14 2L12 2C11.4477 2 11 2.44771 11 3L11 13C11 13.5523 11.4477 14 12 14L14 14C14.5523 14 15 13.5523 15 13L15 3Z" fill="#9B9BB1"/>
<path fill-rule="evenodd" clip-rule="evenodd" d="M9 13L9 3L7 3L7 13L9 13ZM10 3C10 2.44772 9.55228 2 9 2L7 2C6.44772 2 6 2.44771 6 3L6 13C6 13.5523 6.44771 14 7 14L9 14C9.55228 14 10 13.5523 10 13L10 3Z" fill="#9B9BB1"/>
<path fill-rule="evenodd" clip-rule="evenodd" d="M4 13L4 3L2 3L2 13L4 13ZM5 3C5 2.44771 4.55228 2 4 2L2 2C1.44772 2 1 2.44771 1 3L1 13C0.999999 13.5523 1.44771 14 2 14L4 14C4.55228 14 5 13.5523 5 13L5 3Z" fill="#9B9BB1"/>
</svg>
Add and use columns icon for planning board links
Thanks for the feedback! I like the suggestions!
Updated the icon.
I have a few questions about the new section:
- Will the section title be hidden if there are no active plugins? (IMO it makes sense to hide it)
- What happens to the section title when the sidebar is collapsed?
- What about mobile? I’ve just added it as a new item on the bar for now, but that’s not very scalable as more plugins come in. (Maybe a menu similar to the settings with all the plugins?)
No need to answer these right now. Let’s decide if we’re going forward with the plugin-way first