Skip to content
New 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

Open
Moonbase59 opened this issue May 8, 2021 · 3 comments
Open

0.3.3: Interprets YAML frontmatter string as Luxon Duration! Argh! #189

Moonbase59 opened this issue May 8, 2021 · 3 comments

Comments

@Moonbase59
Copy link

@Moonbase59 Moonbase59 commented May 8, 2021

Looks like 0.3.3 interprets YAML data, which it probably shouldn’t?

I have

nearby: 500000 m
location: [48.23875, 10.37595]

in my frontmatter (meaning: "nearby" is 500,000 metres), which is needed with dv.current() to dynamically (via YAML) feed my dataviewjs functions. 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?

@blacksmithgu
Copy link
Owner

@blacksmithgu blacksmithgu commented May 9, 2021

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?

@Moonbase59
Copy link
Author

@Moonbase59 Moonbase59 commented May 9, 2021

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 dv.pages(): Put things in extra quotes ('"500000 m"') and removing them in the code.

But I’m unhappy with this awkward syntax, for several reasons:

  • it’s (in my eyes) done to repair something that is already broken
  • it’s not logical or YAML-syntax-like
  • it’s hard to remember where and why to use it
  • it requires extra steps in code to remove the quotes
  • on small screens, the multiple ' and " are really hard to distinguish, and auto-quote-pairing often hits in so you have to undo that

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 date(today) - this.birthday become possible in the first place.

Taking a fresh perspective on it all (just thinking out loud), what would happen if …

  • you’d not pre-interpret YAML
  • you’d require users to explicitly specify how to use a YAML value
    • YAML to be used as a datetime: use, say, date(this.birthday) or date(birthday) (this would also allow adding a .format() easily, as requested by many)
    • YAML for durations use dur(duration)
  • Would you lose your user base?
  • Or make them totally unhappy because they’d need to change code?

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.

@Moonbase59
Copy link
Author

@Moonbase59 Moonbase59 commented May 9, 2021

Pre-interpreting seems to have other effects, too:

I just found that I can’t display a Luxon duration:

---
#searchterm: "#family or #friends"
searchterm: '"People"'
duration: 2 weeks
---

<%+ tp.frontmatter.duration %>
`= this.duration`

`= date(today) + this.duration`

will display

2 weeks
= this.duration
So., 23. Mai 2021

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 = date(today) + dur(this.duration) in this case.)

(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".)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants