Skip to content

Conversation

@trekforever
Copy link

Discussion

Right now, we can set a RC server template via the constructor. Customers, however, would need to update the template multiple times. The current API exposes template.cache, but that feels more like an internal detail than an API now.

  • Mark ServerTemplate.cache as private, and should only be used with-in the class
  • Add a new ServerTemplate.set to allow for setting the template or templateJSON
  • Add a ServerTemplate.toJSON to return JSON representation (ServerTemplateData) of the template
  • Update InitServerTemplate to make use of the new set method.

Testing

Added new unit tests for the new set method. Update existing tests to make use of toJSON() instead of the cache.

API Changes

  • ServerTemplate.cache is now private and cannot be accessed outside of the class
  • New ServerTemplate.set to allow for setting the template or templateJSON
  • New ServerTemplate.toJSON to return JSON representation (ServerTemplateData) of the template

@trekforever trekforever requested a review from erikeldridge April 5, 2024 01:37
} else {
template.cache = options?.template;
}
template.set(options?.template);
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice, intuitive reuse of set 👍

@trekforever trekforever requested a review from erikeldridge April 5, 2024 20:50
const initializedTemplate = remoteConfig.initServerTemplate();
initializedTemplate.set(template);
const parsed = initializedTemplate.toJSON();
expect(parsed).deep.equals(template);
Copy link
Contributor

Choose a reason for hiding this comment

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

This is very readable 👍

.to.throw(/Failed to parse the JSON string: ([\D\w]*)\./);
});

INVALID_PARAMETERS.forEach((invalidParameter) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Thinking: it feels like we're re-testing the cases covered by the tests on ServerTemplateDataImpl. Looking at the tests, I see us already doing this on the tests for initServerTemplate and load. Makes me think there's an opportunity for a later change to extract ServerTemplateDataImpl to the internal dir so we can test it directly.

@trekforever trekforever self-assigned this Apr 8, 2024
Copy link
Member

@lahirumaramba lahirumaramba left a comment

Choose a reason for hiding this comment

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

LGTM! Thanks!

* Sets and caches a {@link ServerTemplateData} or a JSON string representing
* the server template
*/
set(template: ServerTemplateDataType): void;
Copy link
Member

Choose a reason for hiding this comment

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

Just curious (because I think either is fine) so we need a separate type for this or should this just be ServerTemplateData | string here?

Copy link
Author

Choose a reason for hiding this comment

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

I think either works, I originally had it as ServerTemplateData | string but we are defining it in quite a few places across multiple files, so I moved it to a type 😃

@trekforever trekforever merged commit 86f4426 into ssrc Apr 9, 2024
@trekforever trekforever deleted the ssrc-set-template branch April 9, 2024 17:44
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