Proof of concept: calculations and variables

[hughess]

Proof of Concept for Discussion

• Supports calculations by adding a variables store and allowing for reference of these variables from within components
• Adds CalcInput, CalcSubtotal, and CalcTotal components which provide formatting for displaying values in financial summary style
• CalcInput includes Excel cell-style formatting for editing values
• Uses Svelte reactivity to update calculated results immediately on the page

Drawbacks & Considerations

• Syntax is not very clean or simple
• There is likely a better way to format inputs to make it more apparent that they are editable and that they will impact the calculated cell results immediately, but need to keep in mind print and PDF formatting
• We may want to extend these concepts into a broader Evidence "modeling" feature which allows users to include elements like number inputs and calculations into a formatted "model"
• This would introduce the need for input-level value formatting
• May introduce the need for session-level caching eventually (i.e. if someone changes an input value on a page, should it save for the next time they come back?)

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
evidence-docs	✅ Ready (Inspect)	Visit Preview	Jul 12, 2022 at 5:24PM (UTC)

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: a5f2bb50f296fca97b82523b859f32909cc55161

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[mcrascal]

This is really nice.

Syntax is not very clean or simple

I like this approach with stores. IMO This is way better than having to declare in a script tag. I think $input.name might be easier to understand than $variable.name since it lines up with the naming of the component/ props.

We may want to extend these concepts into a broader Evidence "modeling" feature which allows users to include elements like number inputs and calculations into a formatted "model"

Playing with this, I think there are a few other cases where we could extend these ideas:

1. Use this store approach to add client-side filters for query-results <Filter query={query_name} column=region result_name=filtered_query_name/> - uses the type and extents of the column to present a filter.
2. Things that aren't inputs into a spreadsheet style presentation, and more of a UI style input. E.g. a slider to control where a reference line is being set on a chart, that type of thing.

May introduce the need for session-level caching eventually (i.e. if someone changes an input value on a page, should it save for the next time they come back?)

I think you could get away without it for v1. I kind of expected a page refresh to get me back to the defaults. I think if you did preserve these for the user, you'd also want a "reset" button.