My understanding is that any svelte components should support typescript, you just have to

<script lang="ts">

at the top. With

.md

files, I'm less sure. Our markdown processor MDsveX doesn't officially support TS. But I think some people have made it work in other projects

I also might need to add the typescript preprocessor to the svelte.config file which Evidence defines

@bland-thailand-4711 might be able to shed a bit of light on this when he comes online! (CDT)

What's your exact error in the console?

let me reproduce where I was and let you know the error

my sense is this should be achievable. but we might have to mess around with what evidence does under the hood to achieve it

(Also I know I owe you a meeting! Will grab time when I return home)

potentially relevant? (though old)

working on getting it back up to share the error now

I probably can’t get a minimal gist or reproduction at the moment but could in the future for sure

Yeah no rush with a repro, I'll be around; feel free to drop me an @

I'm assuming you added your own

tsconfig.json

?

(not confident that it is correct, either…)

perhaps I need to redefine the

paths

values?

It would need to be in the tsconfig that you're working on, and I think it would be

./.evidence/template/src/components

that did it

will that work during build? I suppose only one way to find out!

There are a number of issues related to the overall project, but that's where this should end up living

Honestly this might be better than actual typescript support for our use case (though having compile-time errors would be great via typescript). For context, our process is, effectively, 1. Leverage Evidence to build a dashboarding framework with the bells and whistles defined by our design team but which requires minimal to no knowledge of javascript. Ideally you only need to know SQL and some basic patterns of the dashboarding framework itself 2. Implement the first few dashboards as the engineering team; cleaning up, simplifying, and documenting the framework as we go 3. Handoff the framework (with a migration period) to our data analytics team to maintain existing and build new dashboards 4. Iterate, as the engineering teams improve the framework and add more features based on design needs in some low-touch model

I’ve implemented five major paradigms on top of evidence that I think generally identify our needs beyond where the product sits right now • The ability to dynamically override echarts options for any particular chart beyond what evidence offers, but in some encapsulated way - effectively following the evidence paradigm for exposing only a subset of echarts features. We just need more. I created a WrappedChart component for this purpose that passes down props and dynamically overrides config via the echarts API upon certain events (primarily renders and filter changes - see below) • Dynamic global filtering - we have date range filters that sit at the top level of the page and are ◦ synced to/from the URL, for sharing links ◦ In a SPA rather than routing that requires page reloads (long story here, but this is both our UX goal and separately we couldn’t handle a multi page app in the way we’re currently hosting it in an iframe within our larger product. That second limitation of routing is short term) • Chart level filter - examples including toggle buttons to change the series/grouping and single/multi select to filter the dataset passed into the evidence component ◦ In the future, I need to add the ability to have a single filter impact multiple charts but I haven’t settled on a design yet • SQL syntax instead of JS - I don’t want our analytics team to need to learn javascript or functional programming in order to work with the filters. As a result, I started to use alasql , which is great! But has some issues (a few bugs, and performance may become an issue). I’m sure that there are better alternatives • Some minor UX bells and whistles (eg a menu component to allow downloading data or saving as JPEG instead of the out of the box UX, which was simple to add) Example component:

<WrappedChart
                query={`
                    SELECT
                        COUNT(DISTINCT redacted1) AS redacted2,
                        redacted3
                    FROM ?
                    GROUP BY redacted3
                    ORDER BY redacted3
                `}
                queryParams={[datasetCurrTimePeriod_full]}
                title="Participation by Redacted3"
                subtitle="Short subtitle to help explain the data"
                showTitleMenu=true
                x=redacted3
                y=redacted2
                swapXY=true
                chartType=bar
            />

That all sounds great - would love to watch anything if it makes sense, though I can certainly be patient

Also interested in echarts specific ideas of click actions -> filter. This is chart interaction grammar stuff .... so gets complicated fast. Just curious on aim/direction/scope.