i guess we could make a new coder.com/chat link? or at least add a utm_source to the discord.gg url which i think the statistics do give us (unsure, need to check)

Thanks for flagging it! We can update the link in a follow up since I don't know who owns these links.

Just asking because it sounds like I'll be helping out more withcoder/coder's backend soon: what uses theenums struct tags?

mainly swagger generator + if we enable go validation, then the field will have restricted values too.

I'm wondering if it might be better to make thesupportLinks prop required forNavbarView, and then change the checks to see whether the array is empty. That way we don't have to deal with both the empty and undefined cases

And if we do that, we can simplifyuniqueLinks to:

constuniqueLinks=[...newSet(appearance.support_links)]

To be honest, I don't know if I'veever seen the thirdself argument used in professional code before

Set is equality by identity. they'll be separate objects with different identities. you'd still have duplicates in your list using that code.

this kind of uniqueness constraint really feels like something that should be enforced by the backend imo, but if we need to do it on the frontend then I would use aMap and usename as the key, then get the list back by doing[...supportLinksMap.values()]

specifically, here's my suggestion:

tho I still think that data hygiene concerns like this belong more in the backend than that frontend

it's also worth noting that this "call a function if it exists, and give me undefined if not" pattern is common enough that it has it's own operator:?.

Oh right, duh. I forgot that these were objects. Another option would be to do this:

constuniqueLinks=[  ...newMap(appearance.supportLinks?.map((l)=>[l.name,l])).values()];

Though the nuances change a little bit. Kayla's suggestion always keeps the first entry that is encountered when you have a conflict, while mine keeps whichever one occurs later in the array

I wouldn't touch the backend side now, but we can improve it in a follow-up. I updated the frontend side as you suggested. Please let me know your thoughts.

This part works, but it feels a little clunky to me, because the boundaries aren't super clear. When you look at just this component, you can tell that you're rendering out multiple links, but you don't know how they'll be laid out, because you have to look at the parent component to see what kind of container it's using. It's also hard to reuse the link styling/logic because you can't use one by itself

I feel like a better approach would be to change this component intoSupportButton (singular), and then update the navbar to this:

<divclassName="hidden md:block">{supportLinks.filter(isNavbarLink).map((link)=>(<SupportButtonname={link.name}target={link.target}icon={link.icon}location={link.location}/>))}</div>

I think keeping the container/layout logic closer together also makes another question more obvious: do we want to make this aul list?

Refactored intoSupportButton components, but had to move<div className="hidden md:block"> to iterations, otherwise buttons were unaligned as you spotted on Chromatic. Let me know if there is a better solution, but definitely don't want to refactor the entire file to ul/li :)