Skip to content

[Tracking] Refactor functions with many parameters to use parameter objects #50368

@neil-marcellini

Description

@neil-marcellini

Problem: Many functions in the App repo have a very large amount of parameters, making it very hard to work with them. If you need some data that isn’t available with existing parameters you need to add a new one. The safe way to do that is to add it as an optional param at the end of the list. In order to pass it to the function from an existing call you have to fill in all params between the last one used and this new last param. It’s time consuming to fill out the defaults, and any required params require careful considering. Re-ordering parameters is risky and requires updating all existing calls. Also, we often have cases where we have a transaction object in the component, then call a function passing various fields of the transaction split out into n parameters. Wouldn’t it be so much easier to pass the original object? Sometimes we also pass the ID of the object in Onyx only to retrieve it from an Onyx connection later.

Solution: Gradually refactor functions to take in parameter objects, where it’s easier to re-order. Strive to minimize the number of fields. Group parameters into sensible sub-objects. Avoid duplicate prefixes such as parameters.chat.chatReport, use parameters.chat.report instead. Thrive 😄

Original Slack thread.

To do list

  • Refactor one function as an example. Maybe requestMoney or something that's less critical but has a similarly large number of parameters.
  • Update the style guide
  • Create refactoring issues
Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~021846632713060454080
  • Upwork Job ID: 1846632713060454080
  • Last Price Increase: 2024-10-16
  • Automatic offers:
    • dukenv0307 | Reviewer | 104452249
    • ChavdaSachin | Contributor | 104452250
    • mkzie2 | Contributor | 104791696
Issue OwnerCurrent Issue Owner: @neil-marcellini

Metadata

Metadata

Labels

EngineeringExternalAdded to denote the issue can be worked on by a contributorWeeklyKSv2

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions