not that it needs to be handled in this review, but the more I think on it the more I think basic string mapping should stay at the component level. Slims downs imports && it's the same number of lines. WDYT?

That's fine, and honestly for strings that are primevue constants, I'm not sure we need to defend against typos so aggressively, I'd be fine with just inlining them. It's the custom strings I like seeing pulled out.

A few things here:

From my latest understanding of the mockup, the tree is a drawer not a splitter:

Now this may change, or we may decide a splitter is better, so not married to the idea but just pointing it out.

One thing the mock is showing is that the tree component is accessed by clicking a button in the subheader on many different pages. To me this says it's a lazy loaded component that should be entirely ( or near entirely ) contained, so it doesn't leak logic like setDisplayedRow to the components where it's called. Definitely has room for interesting prop and/or emit patterns to signal updates. This also sorta goes back on the idea that was discussed during sprint planning ( or standup? I forget ) about only showing one scheme in the tree at a time. One would imagine that if you're on the Schemes list page you'd want to be able to open the tree and see a list of all schemes.

Lastly this may just be a naming issue, but I don't love the idea of Base components as frontend patterns. Very similar to templates and IMO contrary to component decomposition. I visualize the concept and scheme pages similar to:

// pages/Concept.vue  AND pages/Scheme.vue

<div>
  <SubHeader />
  <div>
     ... stuff specific to the page
  </div>
</div>

with the Subheader containing the Tree and maybe a listener that tells the tree when to re-render. This is definitely an oversimplified example. Happy to chat to flesh out the idea more if need be 👍

This sounds like it needs some discussion and a follow-up ticket. The splitter was just to get something on the page for the demo.

Lastly this may just be a naming issue, but I don't love the idea of Base components as frontend patterns. Very similar to templates and IMO contrary to component decomposition. I visualize the concept and scheme pages similar to:

I'm okay with that, but I do think we should revisit this once we know what we're doing re: drawer/list of schemes :P

a follow-up ticket

Or better, just repurpose #111.

Removed "base" from the file name. I see the subheading becoming its own component, but I guess I'd rather not polish that until we know where the toggle button goes, otherwise that's a lot of state to pass around before firmed up.

I'm sure this will become its own component, but I don't want to polish it until we know what we're doing. Will there be a toggle button? Does this live in a drawer?

Happy to factor this out into a component once we know whether it should also be the component that contains the Toggle Hierarchy button. (I don't think we know that yet?)