Allow custom components to access existing components and helper functions

[hughess]

Feature Description

Allow custom components to access other components or helper functions within a project.

I'm building a custom component within a standalone project and found myself reaching for a couple of things which my custom component file doesn't have access to:

1. Evidence components (e.g., if I want to include a DataTable in my component)
2. Helper functions (number formatting and title formatting most important here I think)

Goal of Feature

Reuse existing components and functions to build something for a specific use case, without having to contribute it into the main Evidence project.

Current Solution

Build the component within the monorepo and contribute it into the open source project.

Alternative Ideas

There may be a way to import the components I want to use in the script tag. I think ideal solution is to not require an import for things already in the project, but if there's an import statement that can be copy-pasted and then modified, that would work as well.

[archiewood]

I think a workaround here is to import the existing component from $lib?

There's an example in the docs

[hughess]

Ah nice, that does work for components - great. I was using the wrong syntax when I tried the import.

So I think this narrows this issue down to the formatting functions (and any other helper functions we think are important to have access to). I think the formatValue function gets solved if we add an accessible fmt function as we've discussed before. Maybe we also add a fmtTitle function that is generally accessible as well, or a way to import it into a custom component file

[archiewood]

fmt is also now in main.

I suspect you could import { formatValue as fmt } from '$lib/modules/formatting';

Thought it's undocumented, and doesn't happen by default!

[ItsMeBrianD]

For what it's worth; this behavior is going to change somewhat with #878, components now live in @evidence-dev/ui and utilities are in @evidence-dev/component-utilities. The ui package is going to need to be a direct dependency so components will be importable from there, and utilities could be a direct dependency to make other things importable as well.

[hughess]

@ItsMeBrianD after working with a few custom components, I think we need the utility functions to be importable in a custom component.

How hard would it be to have parts of component-utilities be importable?

Some functions I reached for recently when developing custom components:

• fmt (or formatValue)
• formatTitle
• getDistinctCount
• getDistinctValues
• getSortedData
• checkInputs

[hughess]

One other piece that may complicate this. In the Waterfall Chart I built, it needs to access the following because it uses the Chart component under the hood. Is there a way to access context?

import { getContext, beforeUpdate } from 'svelte';
import { propKey, configKey } from './context';
$: props = getContext(propKey);
$: config = getContext(configKey);

[ItsMeBrianD]

Everything in component-utilities should be importable; here's an example https://github.com/evidence-dev/evidence/blob/main/packages/core-components/src/lib/unsorted/QueryStatus.svelte#L11

[hughess]

Ah perfect, thanks! Sorry, I missed this before. I was making mistakes on when to use named imports vs. a default + I was trying to import from the package as a whole rather than the individual js files.

Got it working with the utility functions.

Last question - how would I do these imports from core-components?

import { propKey, configKey } from './context';

[ItsMeBrianD]

It looks like the context values haven't been re-exported; we should probably:

• Move context.js from core-components into component-utilities
• Update references to context.js in core-components to the new update
• Document the context values and what they reference