GamerGirlandCo
commented
1 year ago
- In the case of separate field types, automatically detecting these field types would be tricky, so the user would likely have to tell which String fields that should be parsed in a certain way.
i actually like the idea of separate string field types, and having the user distinguish between them via a dropdown setting. as for how the type would be persisted, i was thinking of using frontmatter like this:
stringfield:
type: html
content: <div>nice job!</div>
marcusolsson
Acylation
HananoshikaYomaru
LynetteCullens
simonausten
This issue gathers discussions and issues related to the Projects type system. The plugin was released with a rather simple type system that needs some improvements. Since the type system is a corner-stone of the Projects plugin, a well-designed type system is crucial for the success of Projects.
Rationale
Notes are just text. Text can be incredibly powerful as it can contain pretty much anything, and users can use whichever editor they want to edit it. Unfortunately, the downside of this power is that you can't make any assumptions on pure text.
The purpose of the Projects type system is to extract well-known types of data from pure text so that any views can act as if they communicated with a database.
For example, if Projects detects the text
publish: truebetween a pair of delimiters,---, it detects it as a boolean field (true/false).By defining a piece of text to have a type, we can also define operations on those types. Boolean fields can be toggled on and off. Numbers can be used for mathematical operations.
Since they no longer need to care about parsing text, views become easier to build. And since they have a shared understanding of the data, the user can define the data once, and view it in many different ways.
Design
The type system is the same regardless of where the data came from. In Projects, data sources acts as translation layers (or adapters) that convert data into the shared data format.
For example, the front matter data source knows how to convert from YAML front matter, and the Dataview data source know how to convert the Dataview result into a shared format.
Challenges
Fields have multiple types
Consider the following two notes:
When the data source read the first note, it detects
publishas a boolean field. When it reads the second note, it detectspublishas a numeric field. Since the type system can't determine the type, it needs to fall back to a common denominator. Hencepublishis detected as a String field.Related issues:
71
100
183
Missing type information
If a field is empty (
null) in all notes, there's nothing we can use to detect the type. In this case, the plugin should fall back to a String field.Complex types
Notes may also contain complex type. For example, the Kindle plugin adds the following front matter:
Projects should not attempt to edit fields it doesn't understand. Ideally, I'd like to detects these as nested types, types that can contains other types. That way, you could still build a Kindle view that understands the field value. Other views might not even display them.
Repeated fields
Consider the following examples where
valuesis a field containing multiple values that may or may not share the same type.I propose that we introduce a
repeatedproperty for each field. The type of the field is detected as if the repeated values came from separate notes. For example, in the first example,valueswould be detected as a repeated number, and in the second example, it would be a repeated string (because of falling back to string).Rich-text support
In the following example, all of these front matter properties would be detected as text (string) fields:
Related issues:
66
64
Fields derived from Markdown content
The type system should support Markdown elements, such as tasks. Ideally, I'd like to find a way to avoid creating specific types for Markdown content, but rather reuse the standard types.
Markdown elements could be represented as repeated fields. For example, tasks could be typed as repeated boolean fields and headings as repeated string fields.
Related issues:
149
164