What does setting the target like this do? The MDN docs make it out like this is only useful if you wanted to target the new context with an anchor or form. More over it actually says that whitespace isn't allowed. Would one of the built in target keywords be better for this?

Do we not want users to be able to stop workspaces from the table view anymore? I see in the designs there is a dropdown menu that will have this. Is that going to be a fast follow to this PR?

Yes, the "more options" menu will be implemented in a different PR.

nit:

location.href = getVSCodeHref("vscode", {
	owner: userName,
	workspace: workspaceName,
	token: key,
	agent: agentName,
	folder: folderPath,
});

nit: These two could be combined into one variable and one check

Yeap, but I think this way the code make it more explicit that we are looking for the first non-hide resource and after, the first agent. What do you think?

Honestly I don't think either are particularly readable 😅 . I think my preference would be the one variable with a comment above explaining. I think a comment would be especially if it includes this info from your comment below:

Coder is pretty flexible and allows an enormous variety of use cases, such as having multiple resources with many agents, but they are not common. From my experience dealing with customers, the most common scenario is to have one single compute resource with one single agent containing all the apps, but Idk this in numbers. My idea is to test this as it is, getting the apps for the first resource, and first agent - they are sorted to return the compute resource first - and see what customers and ourselves, using dogfood, think about that.

nit: if you want to use this variable I think it'd be better to have it closer to where it's actually used

Probably out of the scope of this PR but can a workspace have more than one resource that can then also have more one agent? Do we need to check all the resources and all the agents? Right now we're only checking if the first resource's first agent has one these apps, do we need to check if all of them do? Something like:

	const agents = workspace.latest_build.resources
		.filter((r) => !r.hide)
		.flatMap((resource) => resource.agents ?? []);

	if (agents.length === 0) {
		return null;
	}

	const displayApps = new Set(agents.flatMap((agent) => agent.display_apps))
...

But if this is the case a lot of the other code would need to be re-thought too

Probably out of the scope of this PR but can a workspace have more than one resource that can then also have more one agent?

Yes.

Do we need to check all the resources and all the agents?

Nops.

Right now we're only checking if the first resource's first agent has one these apps, do we need to check if all of them do?

Not right now.

For each agent we have two type of apps, built in apps such as VSCode, VSCode insiders, and terminal, and we also have the apps defined by the user (it is coming in a next PR). If we want to show the apps from all the agents, we would need to include all of them, which could make the UI a bit confusing like having two or three terminal buttons.

Coder is pretty flexible and allows an enormous variety of use cases, such as having multiple resources with many agents, but they are not common. From my experience dealing with customers, the most common scenario is to have one single compute resource with one single agent containing all the apps, but Idk this in numbers. My idea is to test this as it is, getting the apps for the first resource, and first agent - they are sorted to return the compute resource first - and see what customers and ourselves, using dogfood, think about that.

Understood! Left a comment above that I think this would be useful info to document into the code