Skip to content

support dataclasses for component args #1074

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

daniel-ohayon
Copy link
Contributor

Summary:
This change adds the ability to provide component arguments via a single dataclass (which can still be combined with positional varargs).
One motivation for supporting dataclasses is to facilitate composition of components, eg consider a scenario where component2 is an extension of component1 – it takes the same args as component1 + some extra ones, calls component1 and does some extra work on top with the additional arguments.

Before

def component1(arg1: str, arg2: int, ...argN: str): ...

# need to repeat all arguments, unclear which ones are specific to component2
def component2(arg1: str, arg2: int, ... argN: str, otherArg: str):
    # need to pass all component1-specific args to component1 explicitly
   app_def = component1(arg1, arg2, ... argN)
   return do_something(app_def, otherArg)

After

dataclass
class Comp1Args:
   arg1: str
   arg2: int
   ...
   argN: str

# separation of args for the 2 components is explicit via the dataclasses
# no need to spell out all the args thanks to inheritance
dataclass
class Comp2Args(Comp1Args):
   other_arg: str

def component1(args: Comp1Args): ...

def component2(args: Comp2Args): 
     # no need to spell out all the args when calling component1
    app_def = component1(args)
    return do_something(app_def, other_arg)

Differential Revision: D75320316

Summary:
This change adds the ability to provide component arguments via a single dataclass (which can still be combined with positional varargs).
One motivation for supporting dataclasses is to facilitate composition of components, eg consider a scenario where `component2` is an extension of `component1` – it takes the same args as component1 + some extra ones, calls `component1` and does some extra work on top with the additional arguments.

## Before
```lang=python
def component1(arg1: str, arg2: int, ...argN: str): ...

# need to repeat all arguments, unclear which ones are specific to component2
def component2(arg1: str, arg2: int, ... argN: str, otherArg: str):
    # need to pass all component1-specific args to component1 explicitly
   app_def = component1(arg1, arg2, ... argN)
   return do_something(app_def, otherArg)
```
   
## After
```lang=python
dataclass
class Comp1Args:
   arg1: str
   arg2: int
   ...
   argN: str

# separation of args for the 2 components is explicit via the dataclasses
# no need to spell out all the args thanks to inheritance
dataclass
class Comp2Args(Comp1Args):
   other_arg: str

def component1(args: Comp1Args): ...

def component2(args: Comp2Args): 
     # no need to spell out all the args when calling component1
    app_def = component1(args)
    return do_something(app_def, other_arg)
```

Differential Revision: D75320316
@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label May 27, 2025
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D75320316

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. fb-exported
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants