• Blog
  • Docs
  • Pricing
  • We’re hiring!
Log inSign up
lightweight

lightweight

todoSweeper

Public
Like
todoSweeper
Home
Code
12
.claude
1
backend
6
frontend
4
shared
3
.vtignore
AGENTS.md
CLAUDE.md
README.md
deno.json
H
main.http.tsx
mappingPlan.md
notion.config.ts
Branches
2
Pull requests
Remixes
1
History
Environment variables
13
Val Town is a collaborative website to build and scale JavaScript apps.
Deploy APIs, crons, & store data – all from the browser, and deployed in milliseconds.
Sign up now
Code
/
mappingPlan.md
Code
/
mappingPlan.md
Search
12/30/2025
Viewing readonly version of main branch: v220
View latest version
mappingPlan.md

mapping plan

we were planning how to handle saving todos from source to the todos database. we had decided that we would leverage a few strategies to handle mapping todo source content to properties in the todos database.

mapping strategies

strategy 1: explicit mention mapping

when a todo mentions a page in a database that is a relation in the todos database, the page id of the page that was nentioned should be added to the corresponding relation property in the todos database.

we may add relations at any time and remixes of this val are likely to have new relations that the user should be able to add that just work.

to enable this, the notion.config.ts file should probably have a new array that lists the properties in the todos database that are relations. when a mention is picked up by search, we see the id of the page and the id of the parent database and we use that to put the mention in the right property in the todos database. confirm.

note that projects are special relations. a todo should almost always map to a project and we should handle that association as best we can and so some of the 'smart' stuff we're doing to match projects to todos should remain, but our connection between projects and todos can be simple like the other relations -- when we map the 'projects' key to the relation in the todos database, our app should be smart enough to know that that one is for projects and should have special treatment.

ideally, we can use our new approach to mentions to handle the connection between projects and todos. projects are just a special type of mention and the app will know this and so we no longer need to explicitly set the env var for the projects database. explain whether or not this is a good idea and what would change if we went this way.

when there are hits like this, we don't need to add these mentions to the Links property of the todos database. Links will work as a catch-all for links and mentions that aren't mapped to properties in the todos database.

strategy 2: contextual mapping

when a todo in a page that is in the projects database, we can assume that the todo relates to that project.

can we follow this approach for any todo that is in any page that has properties? as in, if the todo is in a page that has properties that maps to the relations properties array in notion.config.ts, can we use those? should we use those? explain.

caching

the process starts with search to find the most recently edited pages, so we have page context and page property values before we even find todos and we should use all that to handle contextual mappings.

priority

explicit mentions should trump contextual mapping.

FeaturesVersion controlCode intelligenceCLIMCP
Use cases
TeamsAI agentsSlackGTM
DocsShowcaseTemplatesNewestTrendingAPI examplesNPM packages
PricingNewsletterBlogAboutCareers
We’re hiring!
Brandhi@val.townStatus
X (Twitter)
Discord community
GitHub discussions
YouTube channel
Bluesky
Open Source Pledge
Terms of usePrivacy policyAbuse contact
© 2026 Val Town, Inc.