https://evidence.dev logo
Join Slack
Powered by
Hey! Any thoughts on being able to split a single ...
# random
a
Hey! Any thoughts on being able to split a single .md file into multiple? Example - I have a tabbed dashboard and would love for it to be managed as a .md file for each tab - or at least a partial file that can be imported into the outer parent
b
Partials are an excellent idea. We haven’t looked at this in earnest, but I suspect it’s not a huge leap, since the pages themselves are being compiled into svelte components. Where would you want to store the partials? In the components directory?
a
I subdirectories for our use case. Our general structure is:
--> pages directory --> dashboard1 directory --> page.md --> dashboard2 directory --> page.md --> dashboard3 directory --> page.md We do this because we’re using Evidence for a multi-tenancy datastore and we created a build script that builds each page separately
so if we could split those page.md files into multiple files with a top level page.md, that would be amazing
Copy code
--> pages directory
  --> dashboard1 directory
     --> page.md
     --> tabs
       --> tab1.md
       --> tab2.md
       --> tab3.md
  --> dashboard2 directory
     --> page.md
  --> dashboard3 directory
     --> page.md
something like that
(and great news!)
For other context - all of the pages share a common design language and custom components, so they share assets from the components directory
b
I think the opposite pattern could also be useful in some cases: • Split a single md file into multiple outputs. I could imagine the being helpful for a "slide export" format
Copy code
# Page 1 Headline

Some content

---

# Page 2 Headline

Some other content

---

etc
a
Totally! Not for us at this point, but that certainly makes sense
b
ah pretty interesting — co locating them with pages does look ideal. Would it still be workable if partials lived in components or their own top level directory?
a
Thanks! As for where - our intention is to hide the technical complexity from users writing dashboards, so ideally they would not live in the components directory. We’re treating that as more “behind the curtain”. But it is of course workable
We effectively split our team into • less technical but more data and end-client focused team members who write dashboards using existing patterns (from other dashboards) and SQL • more technical engineers who iterate on the framework to enable the above members
b
Very cool, and makes perfect sense.
Open in Slack
PreviousNext
Powered by