这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@Ekrekr
Copy link
Contributor

@Ekrekr Ekrekr commented Jan 2, 2024

No description provided.

@Ekrekr Ekrekr requested a review from lewish January 2, 2024 15:47
constructor(session?: Session) {
constructor(session?: Session, config?: dataform.ActionConfig) {
super(session);
if (!session || !config) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I see why you do this - a slightly cleaner / less error prone way would be to overload the constructor to have a 0 params form and a 2 params form where they are both required, e.g: https://stackoverflow.com/questions/12702548/constructor-overload-in-typescript

Copy link
Contributor Author

@Ekrekr Ekrekr Jan 2, 2024

Choose a reason for hiding this comment

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

This doesn't seem to work the way one would expect it to with type overloading.

image

How about now, where just the presence of config is checked?

declaration.proto.fileName = utils.getCallerFile(this.rootDir);
public declare(declarationConfig: dataform.ITarget | dataform.ActionConfig): Declaration {
// The declaration property exists on ActionConfig but not on Target.
if (!declarationConfig.hasOwnProperty("declaration")) {
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 pretty nasty! Two paths here and two paths in the constructor...
Surely there must be a way to push this all into the constructor at least?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This has to be nasty somewhere in order to preserve the previous functionality - one alternative would be to just stop supporting Target as a parameter.

I'm not keen for it being in the constructor, because I think it obfuscates that it is the method on session that contains deprecated functionality, as opposed to the class constructor which isn't something the user can call directly.

Copy link
Contributor

Choose a reason for hiding this comment

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

I still think there probably is some way to make this a little nicer, but I see you have a pattern here so let's stick to that until we see a better way :)

@Ekrekr Ekrekr requested a review from lewish January 2, 2024 16:36
declaration.proto.fileName = utils.getCallerFile(this.rootDir);
public declare(declarationConfig: dataform.ITarget | dataform.ActionConfig): Declaration {
// The declaration property exists on ActionConfig but not on Target.
if (!declarationConfig.hasOwnProperty("declaration")) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I still think there probably is some way to make this a little nicer, but I see you have a pattern here so let's stick to that until we see a better way :)

@Ekrekr Ekrekr merged commit 5a80b9e into main_v3 Jan 2, 2024
@Ekrekr Ekrekr deleted the declaration-actions-yaml branch January 2, 2024 16:40
moker-spaghetti pushed a commit to moker-spaghetti/dataform that referenced this pull request May 26, 2024
* Add support for declarations via action config files

* Tidy

* Fix lint

* Tidy constructors
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