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

Opting out of date auto-inferring? #3885

Closed
tremby opened this issue Feb 7, 2018 · 15 comments
Closed

Opting out of date auto-inferring? #3885

tremby opened this issue Feb 7, 2018 · 15 comments

Comments

@tremby
Copy link
Contributor

tremby commented Feb 7, 2018

I'm loading data from Markdown files and in my frontmatter I have some date fields.

I've got some dates with no known day; just YYYY-MM (which is a perfectly valid ISO date form). Others are just a year. Others are a full date. All are timezoneless. But no JS date-handling library I'm aware of actually knows how to properly handle incomplete dates. They all treat them like the first of the month or first of the year.

I want to handle these dates in my template, with different behaviour depending on the resolution of the date. So I want to get them as is.

But when I load the data via GraphQL the ones which look like full dates are being converted into datetime strings in the UTC timezone. The others are being left alone. This makes it difficult for me to treat them separately. I can test by regex to see if it's just a year, or a year and a month, and handle those properly. But if it's a full datetime string I need to cut off the time and time zone part (otherwise when parsing it and then formatting it again it might change date due to my time zone offset), and this is a mess I'd really rather avoid.

I just want to opt out of auto-inferring dates. Can I do that?

Better yet, I want to manually specify the transformation to make when these particular fields are requested.

@KyleAMathews
Copy link
Contributor

If you just query the field without adding arguments for transformations, it'll return the original string. Is that not what's happening? Date fields are just fancy string fields with extra transformation options.

@tremby
Copy link
Contributor Author

tremby commented Feb 7, 2018

That's not what I'm getting out. With writeupDate: 2018-02-06 in my frontmatter I'm running console.log(frontmatter) and getting out ..., writeupDate: "2018-02-06T00:00:00.000Z", ....

@KyleAMathews
Copy link
Contributor

Oh that's https://www.npmjs.com/package/gray-matter that does that. If you surround the date in a string, it'll retain the original formatting. I filed an issue (jonschlinkert/gray-matter#62) about disabling date parsing.

@tremby
Copy link
Contributor Author

tremby commented Feb 7, 2018

Why should surrounding it in quotes do anything? Bare things which aren't bools or ints etc in YAML are strings anyway, are they not?

@KyleAMathews
Copy link
Contributor

gray-matter converts non-quoted bare dates to date objects.

@tremby
Copy link
Contributor Author

tremby commented Feb 7, 2018

I dislike magic. When I'm told frontmatter is YAML, that's what I expect.

@KyleAMathews
Copy link
Contributor

@tremby turns out parsing dates is in the YAML spec 🤷‍♂️ jonschlinkert/gray-matter#62 (comment)

@KyleAMathews
Copy link
Contributor

Seems what most people suggest is if you want to ensure a string in YAML is interpreted as a string than surround it in quotes as YAML supports several other data types that your bare data will be parsed into nodeca/js-yaml#161

@tremby
Copy link
Contributor Author

tremby commented Feb 7, 2018

Well what an idiot I feel. YAML does a lot more than I thought it did. Thanks for looking into it for me, and sorry for the noise.

The part of the YAML spec about these timestamps: http://yaml.org/type/timestamp.html

It turns out that another way to ensure it's treated as a string is to hint which "tag" should be used. The following all cause it to stay a string:

  • date: "2018-02-06" (as you pointed out)
  • date: ! 2018-02-06 ("non-specific tag", which limits it to string, map, or sequence)
  • date: !!str 2018-02-06 (specifically use the built-in string tag)

One thing I'll suggest (and therefore leave this open for now) is that the docs are a bit clearer that this auto-inferring of types from frontmatter via GraphQL isn't Gatsby magic -- it's just what YAML does anyway. Or is that not strictly true in all cases?

@KyleAMathews
Copy link
Contributor

Or is that not strictly true in all cases?

It's js-yaml -> gray-matter -> gatsby — we don't touch the data after we get it from gray-matter.

@KyleAMathews
Copy link
Contributor

Would you like to document this better in gatsby-transformer-remark's README?

@tremby
Copy link
Contributor Author

tremby commented Feb 7, 2018

Honestly it might suffice just to replace ". TODO link to docs on auto-inferring types/fields" with "via gray-matter [link]". I think it was this "TODO" tag which put me under the impression that Gatsby was doing a bunch of processing I'd have to fight in the edge cases!

@KyleAMathews
Copy link
Contributor

🤦‍♂️ oh my — I wrote that like a year ago or whatever. Yes, your update is definitely needed :-)

@KyleAMathews
Copy link
Contributor

Due to the high volume of issues, we're closing out older ones without recent activity. Please open a new issue if you need help!

@tremby
Copy link
Contributor Author

tremby commented Sep 9, 2018

I just opened a PR which changes the TODO as I suggested.

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

No branches or pull requests

2 participants