blacksmithgu / obsidian-dataview Public
generated from obsidianmd/obsidian-sample-pluginNew issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0.3.3: Interprets YAML frontmatter string as Luxon Duration! Argh! #189
Comments
|
For what it's worth, it has done this since it's first release - it just usually works since types are generally unambigious (numbers are numbers, text is text, etc). The only pre-processing that is done on strings is to extract dates and durations, which is what you ran into for durations. I'm wondering what the proper remediation is. Maybe an escape character of some sort? |
|
Yes, I see, delving deeper into all this stuff. That’s where the (for me) odd-looking data format comes from. I can see it makes things easier for "simple tables & lists" that your plugin was meant for, of course. It’s not always easy to build a bridge between ease-of-use and the flexibility you get by more "programmer-like" interfaces. This is also a problem I see with Obsidian in general: More and more users mess with plugins, CSS, wild workarounds and stuff instead of simply using it for a purpose. It’s already far from anything like "compatible Markdown". But well, we get so much of extended value, it might be worth it. :-) Personally, I prefer variables I put somewhere (like YAML) to stay unchanged and if I want to do something with them, do it myself. (I’d have been happy with dates in DV tables appearing like YYYY-MM-DD, for instance. Ok, maybe with a formatting option.) To get around my duration problem, I temporarily use the syntax you use if specifying folder names for But I’m unhappy with this awkward syntax, for several reasons:
I’d favour a solution that didn’t need additional quirks to circumvent stuff (like extra escapes)—going such a way will eventually make things over-complicated, and code harder and harder to maintain. Trust me, I’m speaking of 45 years (shocked myself!) of IT experience. I reckon the problems come mainly from needing datetimes, and somehow preparsing the YAML to have any possible datetime and/or duration already available. Thus niceties like Taking a fresh perspective on it all (just thinking out loud), what would happen if …
Some, maybe. Overall, I think not. Maybe this could be something to think about? And yes, I like Dataview. A lot. Of course it has its quirks, is not always easy to handle, has to outthink caching, and so forth. BUT it makes unthought-of and much-needed things possible. |
|
Pre-interpreting seems to have other effects, too: I just found that I can’t display a Luxon duration: will display so Templater shows it correctly, Dataview can’t for some reason (no errors in console) but it can use it for calculations. (Re my idea above: I really wouldn’t mind having to write (I’m working on a better version of "Upcoming birthdays" and wanted it to be controllable via YAML, by having a "natural" duration there and displaying it later as "Upcoming birthdays in the next 2 weeks".) |
Looks like 0.3.3 interprets YAML data, which it probably shouldn’t?
I have
in my frontmatter (meaning: "nearby" is 500,000 metres), which is needed with
dv.current()to dynamically (via YAML) feed mydataviewjsfunctions. I can’t now split() this string and build a radius and unit from it for my Dataview table.I do understand it’s convenient to "pre-evalute" YAML frontmatter (like for dates), but it can have unwanted side effects. What can be done?
The text was updated successfully, but these errors were encountered: