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

Dynamic config resolver schemas and types #793

Conversation

Assem-Hafez
Copy link
Contributor

@Assem-Hafez Assem-Hafez commented Jan 17, 2025

Summary

Adding validation schemas for config resolvers (args/return types) & use those schemas to validate the input/output of resolvers on runtime.

Add evaluateOn flag to configs to define when resolvers are being executed. It supports request & serverStart.

Add isPublic flag to configs to identify which configs are accessible from client code.

Changes

  • Extract logic from getTransformedConfigs to transformConfigs for better testing (doing the same for get-config-value.ts in upcomming PR)
  • Add schemas directory under configs as they can also be modified
  • Add evaluateOn & isPublic flags
  • Refactored types

Upcoming plans

  • Revisit naming for Types and functions to make them more understandable
  • better testing for get-config-value.ts

COMPUTED: ConfigSyncResolverDefinition<[string], [string]>;
DYNAMIC: ConfigAsyncResolverDefinition<undefined, number>;
GRPC_SERVICES_NAMES: ConfigEnvDefinition<true>;
DYNAMIC: ConfigAsyncResolverDefinition<undefined, number, 'serverStart'>;
Copy link
Member

Choose a reason for hiding this comment

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

Since these are test configs, it would be good to add a comment above them like you did on Line 41.

Copy link
Member

Choose a reason for hiding this comment

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

IMO the best option would be to have a separate config file specifically for tests

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm going to remove all of the unused/test configs in my second upcomming PR

@@ -30,17 +36,32 @@ const dynamicConfigs: {
GRPC_SERVICES_NAMES: {
env: 'NEXT_PUBLIC_CADENCE_GRPC_SERVICES_NAMES',
default: 'cadence-frontend',
isPublic: true,
},
// For testing purposes
DYNAMIC: {
Copy link
Member

Choose a reason for hiding this comment

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

Since these are test configs anyway, "ASYNC" and "SYNC" would be more meaningful than "DYNAMIC" and "COMPUTED"

Copy link
Contributor

Choose a reason for hiding this comment

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

Removing it in my second upcoming PR

src/utils/config/__tests__/transform-configs.test.ts Outdated Show resolved Hide resolved
};

export type ConfigEnvDefinition = {
export type ConfigEnvDefinition<IsPublic extends boolean = false> = {
Copy link
Member

Choose a reason for hiding this comment

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

nit (as discussed): a union type would be nicer here, just so that we can write ConfigEnvDefinition<'public'> instead of ConfigEnvDefinition<true>

src/utils/config/get-config-value.ts Show resolved Hide resolved
Co-authored-by: Adhitya Mamallan <adi1998is@gmail.com>
@Assem-Uber Assem-Uber merged commit 8eee11f into cadence-workflow:release/4.0.0 Jan 20, 2025
1 check passed
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