Skip to content

Format#322

Closed
unclenachoduh wants to merge 13 commits intoprojectfluent:masterfrom
unclenachoduh:format
Closed

Format#322
unclenachoduh wants to merge 13 commits intoprojectfluent:masterfrom
unclenachoduh:format

Conversation

@unclenachoduh
Copy link
Copy Markdown
Contributor

Fix format for issue #208

Copy link
Copy Markdown
Contributor

@stasm stasm left a comment

Choose a reason for hiding this comment

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

Nice work, @unclenachoduh! Thank you for working on this and for refactoring all the tests!

I have a few minor comments (see below) as well as 3 general ones:

  1. We'll need some tests for the compound API. I can help you get started with a basic test file, if you'd like.
  2. I think with these changes, we can remove the getMessage method now.
  3. (Minor) Let's take this opportunity to write out comments as full sentences, with a capital letter at the front and a fullstop at the end :)

I think this is very close to being good to land. Let me know if you're available to address these comments. I'll be happy to help with any of them, too! Thanks again!

return null;
}

let attr = message.attrs[parts[1]];
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

To keep it consistent with the parts.length === 1 branch above, perhaps you could add an if (typeof attr === "string") fast path? I'm not sure they're needed and I'll do some perf testing when I get a chance. For now it would be best to keep both branches as similar to each other as possible.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure where to place this fast path and which return it correlates to. Should this go in line 229?

@stasm
Copy link
Copy Markdown
Contributor

stasm commented Jan 29, 2019

@unclenachoduh Do you know if you'll be available in the coming weeks to finish this PR? I'd like to land it in early February.

@unclenachoduh
Copy link
Copy Markdown
Contributor Author

Hey @stasm I can get on this weekend to resolve the changes you've asked for. I'm a little busy right now, so I don't think I'll be able to write the new tests for compound.

@stasm
Copy link
Copy Markdown
Contributor

stasm commented Feb 6, 2019

I'll be happy to help with the tests. I'd like to land this next week; let me know if you're still available to apply my feedback. I understand that you're busy so no worries if not.

@unclenachoduh
Copy link
Copy Markdown
Contributor Author

I think I still have one of these changes pending. Take a look at the changes.

const msg = bundle.getMessage('foo');
assert.equal(typeof msg, 'string');
});

Copy link
Copy Markdown
Member

@eemeli eemeli Apr 23, 2019

Choose a reason for hiding this comment

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

It would probably be better to mark this test as skipped with test.skip(...) rather than just removing it.

const msg = bundle.getMessage('bar');
assert(Array.isArray(msg));
});

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It would probably be better to mark this test as skipped with test.skip(...) rather than just removing it.

@eemeli
Copy link
Copy Markdown
Member

eemeli commented Apr 23, 2019

I rather like this API, but I think the getMessage() deprecation ought to be split into a separate follow-on change, because really at the same time the behaviour of hasMessage() and get messages should also be reconsidered.

More specifically, I think hasMessage() should also support the message.attr path format, and get messages (or something like it) should iterate on message keys rather than [key, message] entries. Discussion on these ought to be considered separately from this change, though they are related.

@stasm
Copy link
Copy Markdown
Contributor

stasm commented Apr 23, 2019

I'd like to finish @unclenachoduh's work and land this change soon. To clean things up a bit, I'll squash all commits from this PR and I'll open a new PR keeping attribution of the code written so far.

@stasm
Copy link
Copy Markdown
Contributor

stasm commented Apr 23, 2019

I rather like this API, but I think the getMessage() deprecation ought to be split into a separate follow-on change, because really at the same time the behaviour of hasMessage() and get messages should also be reconsidered.

With format taking an id (or id.attr), there aren't any reasons for keeping getMessages. It returns an internal representation of the message which no other method will be able to work with after the change to format. Do you have other use-cases for it in mind?

More specifically, I think hasMessage() should also support the message.attr path format, and get messages (or something like it) should iterate on message keys rather than [key, message] entries. Discussion on these ought to be considered separately from this change, though they are related.

I'll file new issues about these, as you suggested. Thanks!

@eemeli
Copy link
Copy Markdown
Member

eemeli commented Apr 23, 2019

I have no other use cases in mind for getMessages(). Just wanted to help ensure that the format() & compile() refactoring would not get stuck waiting for the other related issues.

@stasm stasm mentioned this pull request Apr 26, 2019
@stasm
Copy link
Copy Markdown
Contributor

stasm commented Apr 26, 2019

I opened a new PR to continue working on this: #360. I updated and rebased the code and fixed a few issues. I'm going to close this PR now.

@stasm stasm closed this Apr 26, 2019
@stasm stasm mentioned this pull request Apr 29, 2019
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.

3 participants