-
Notifications
You must be signed in to change notification settings - Fork 5
chore: setup initial repo #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Co-authored-by: Asher <ash@coder.com>
/** | ||
* 2024-02-13 - The version of TechDocsAddons that Backstage ships with makes | ||
* the TypeScript compiler complain when you try to render it as JSX. This seems | ||
* like it's just a type mismatch issue, and things still work at runtime | ||
*/ | ||
const FixedTechDocsAddons = TechDocsAddons as React.FC<unknown>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no idea what changed between the last time we set up a Backstage repo from early last year and now, but this was complaining at me, and likely would've caused compiler issues
import { PluginEnvironment } from './types'; | ||
|
||
describe('test', () => { | ||
it('unbreaks the test runner', () => { | ||
const unbreaker = {} as PluginEnvironment; | ||
expect(unbreaker).toBeTruthy(); | ||
}); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the first time I've seen this code. I don't understand why this is here
@@ -0,0 +1,69 @@ | |||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New component
@@ -0,0 +1,34 @@ | |||
import React from 'react'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a new file, but this is the first time it's really being filled out
const isInitializing = | ||
authValidityQuery.isLoading && | ||
authValidityQuery.isFetching && | ||
!authValidityQuery.isFetchedAfterMount; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The one bug fix – authValidityQuery.isFetchedAfterMount
originally wasn't negated. Originally, I thought the name meant "is this query being run immediately after the mounting render?", but it's actually "is this query being run after a re-render?"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch!
@@ -0,0 +1,70 @@ | |||
import { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another file that isn't new, but got filled out with more stuff, and has exports defined more properly this time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't figure out how to get the Proxy available in dev mode
I was looking at Roadie's pull request plugin and I wonder if we drop the proxy stuff and use this API factory thing they are doing. From what I gather it could look something like:
import * as coder from "coder/site/src/api/api" // with "coder": "https://github.com/coder/coder#main" in the package.json as a dependency
export const coderApiRef = createApiRef<typeof coder>({
id: 'coder.api',
})
export const coderPlugin = createPlugin({
id: 'coder',
apis: [
createApiFactory(coderApiRef, coder),
],
routes: {
root: rootRouteRef,
},
})
Then in components:
import useApi ...
import coderApiRef ...
const coderApi = useApi(coderApiRef);
coderApi.getWorkspaces()
I have not tried it but it seems promising! In this example I imported from coder/coder
but we could do it with the existing API stuff.
@@ -0,0 +1,320 @@ | |||
import { parse } from 'valibot'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a note for the future, we should think about pulling from coder/coder
in the way the VS Code plugin does so we can get the sdk and types from there.
If we do this, as a reference the way the VS Code plugin sets the token and URL is:
import axios from "axios"
// ...
axios.defaults.baseURL = url
axios.defaults.headers.common["Coder-Session-Token"] = token
Admittedly kind of janky. At some point maybe we export a proper client factory from coder/coder
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that seems like a much better approach, especially since we have control of the API. Especially as we move towards exposing the whole Coder API (like Ben has planned), adding the types directly is going to be much more maintainable long-term
plugins/backstage-plugin-coder/src/components/ExampleComponent/ExampleComponent.tsx
Outdated
Show resolved
Hide resolved
plugins/backstage-plugin-coder/src/components/ExampleFetchComponent/ExampleFetchComponent.tsx
Outdated
Show resolved
Hide resolved
@code-asher Yeah, I've been wondering about the API factory stuff, too. It just feels weird that the main documentation for proxying makes no mention of them, and they just say to use the native fetch There is this example page, though, which makes use of the discoveryApi. Hopefully this would do the trick, but I've got two big questions (just thinking out loud):
Still, once I get the auth PR done, I'll fiddle around with things, and see if I can't get them working |
Awesome, yeah I think we can punt on the API thing since running from the root works perfectly fine, but curious to see what you turn up! |
This commit lays the groundwork for moving all our Backstage plugin logic into a separate repo that will (eventually) become public and fully open-sourced.
Notes
Changes to watch out for