Skip to content

update runtime config customization to be fully overridable #153

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

Merged

Conversation

AllanZhengYP
Copy link
Contributor

Previously, some default runtime config values are hard-coded into
templates. This change makes each one of the properties(e.g. requestHandler)
to be overridable by customizations from SDK side. If no customization
exists, the generator can still generate SDK with proper dependencies.

This change is added to support the customization of using WebSocket
requestHandler.

This change also brings in the capability that customization applied
later can override the runtime config values added in earlier
customization. This is necessary sometimes. For example, if customization
A adds runtime config: {x: X, y: Y}. x and y are deeply coupled that
they need to be in the same customization. If there's a single client
needs runtime config {x: X, y: Y-update}, we should be able to make
a new customization overriding the original customization.

Issue #, if available:

Description of changes:

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Previously, some default runtime config values are hard-coded into
templates. This change makes each one of the properties(e.g. requestHandler)
to be overridable by customizations from SDK side. If no customization
exists, the generator can still generate SDK with proper dependencies.

This change is added to support the customization of using WebSocket
requestHandler.

This change also brings in the capability that customization applied
later can override the runtime config values added in earlier
customization. This is necessary sometimes. For example, if customization
A adds runtime config: {x: X, y: Y}. x and y are deeply coupled that
they need to be in the same customization. If there's a single client
needs runtime config {x: X, y: Y-update}, we should be able to make
a new customization overriding the original customization.
@AllanZhengYP AllanZhengYP requested a review from kstich March 30, 2020 19:41
@AllanZhengYP AllanZhengYP force-pushed the runtime-config-override branch from 8787fa1 to 481c371 Compare March 31, 2020 01:41
@AllanZhengYP AllanZhengYP force-pushed the runtime-config-override branch from 1443d9d to b8dbafd Compare April 3, 2020 07:55
@AllanZhengYP AllanZhengYP merged commit edca7f6 into smithy-lang:master Apr 3, 2020
srchase pushed a commit to srchase/smithy-typescript that referenced this pull request Mar 17, 2023
…ang#153)

* update runtime config customization to be fully overridable

Previously, some default runtime config values are hard-coded into
templates. This change makes each one of the properties(e.g. requestHandler)
to be overridable by customizations from SDK side. If no customization
exists, the generator can still generate SDK with proper dependencies.

This change is added to support the customization of using WebSocket
requestHandler.

This change also brings in the capability that customization applied
later can override the runtime config values added in earlier
customization. This is necessary sometimes. For example, if customization
A adds runtime config: {x: X, y: Y}. x and y are deeply coupled that
they need to be in the same customization. If there's a single client
needs runtime config {x: X, y: Y-update}, we should be able to make
a new customization overriding the original customization.

* Add ordering to customizations; runtimeConfig needs writing a whole line
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.

2 participants