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

Add support for useDate=false #211

Merged
merged 4 commits into from
Feb 20, 2021
Merged

Add support for useDate=false #211

merged 4 commits into from
Feb 20, 2021

Conversation

ethanfrey
Copy link
Contributor

@ethanfrey ethanfrey commented Feb 11, 2021

Closes #208

  • build example use-date-false that demonstrates this case
  • write unit tests
  • fix codegen

Note for devs:

  • First you must run the setup as described in https://github.com/stephenh/ts-proto/blob/master/README.markdown#building
  • After changing the *.proto file you need cd integrations && ./update-bins.sh
    • You want update protoc --version to be 3.14.0 for this to run properly
  • After changing the codegen logic, you need cd integrations && ./codegen.sh
    • ../node_modules/.bin/ts-node ./codegen.ts ./use-date-false ./use-date-false/metadata.bin useDate=false is faster to generate just one file, and works on macos

@ethanfrey ethanfrey marked this pull request as ready for review February 11, 2021 13:14
src/main.ts Outdated
@@ -576,7 +588,9 @@ function generateDecode(ctx: Context, fullName: string, messageDesc: DescriptorP
readSnippet = code`${type}.decode(reader, reader.uint32()).value`;
} else if (isTimestamp(field)) {
const type = basicTypeName(ctx, field, { keepValueType: true });
readSnippet = code`${utils.fromTimestamp}(${type}.decode(reader, reader.uint32()))`;
readSnippet = options.useDate
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I think it might be a simpler change to leave this line as it was, and then change line 589's "if isTimestamp(field)" to include "&& useDate".

That way we'll only get into this else if if its timestamp & use date is true, otherwise we'll go into the isMessage(field) block next, which I think should handle Timestamp's just fine, i.e. it will basically do that ${type}.decode that currently you have re-typed-out as a the : case.

...could probably do that for most of these if isTimestamp(field) changes?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if isTimestamp should be renamed to isTimestampAsDate, and have it take both options & field, because (...in theory...?) everywhere that isTimestamp is called today, we really mean "...so that we can do special Date handling".

I guess the JSON serialization is the exception to that rule, where we want to detect Timestamp and do something special even if its not a Date.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I've simplified the code where I can and updated the codegen. Since we need isTimestamp to be separable from options.useDate for the JSON serialisation, I guess we could add a wrapper function that checks both, but I don't think that adds much value.

return code`${from} !== undefined ? ${from}.toISOString() : null`;
return options.useDate
? code`${from} !== undefined ? ${from}.toISOString() : null`
: code`${from} !== undefined ? ${utils.fromTimestamp}(${from}).toISOString() : null`;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah cool, keeping ISO strings on the wire...

import "google/protobuf/timestamp.proto";

message Metadata {
google.protobuf.Timestamp last_edited = 1;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great small repro, thanks!

@ethanfrey
Copy link
Contributor Author

Thanks for the review, it will probably be Monday or Tuesday til we get to the fixes, but happy to make them

@ethanfrey
Copy link
Contributor Author

Thanks for the updates Will. Is this blocked on anything @stephenh or just time to review it?

@stephenh stephenh merged commit 92cb60c into stephenh:master Feb 20, 2021
@willclarktech willclarktech deleted the 208-use-date-fix branch February 21, 2021 13:39
zfy0701 added a commit to sentioxyz/ts-proto that referenced this pull request Jan 5, 2023
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

Successfully merging this pull request may close these issues.

Timestamp functions cause issues with useDate=false option
3 participants