Best practices when needing to take in a large number of parameters?

So Im writing a wrapper around this API ReDoc Interactive Demo

Some of the endpoints, like this one ReDoc Interactive Demo (be sure to expand all of the objects to see all that’s needed), need a lot of user input in order to create the proper POST body.

Im at a loss as to how to collect all input from the user. I know its a no no to have a function accept more than 5 params. It also feels weird to have the user input a single param (a big map). They wont know what shape the map needs to be in. It also feels like a cop out to link to the API docs so they can see the map shape possibilities. Also, since the request body can take different shapes i feel that a struct wouldn’t work.

Check out this screenshot for the possible actions.

Thanks for any help / input.

There’s only three required parameters, so you could do:

def build_transaction(network_id, actions, fee_payer, options \\ [])
  at_state_id = Keyword.get(options, :at_state_id)
  ...
end
1 Like

But what about fee_payer, actions

Put them into a map, and you can pattern match on them. If they are not provided, the the cause will not match.
If you want a more descriptive error, make them a keyword list or a map, and validate inside your function.

Certainly not a struct, but consider a bunch of structs:

defmodule BuildTransaction do
  defmodule AccountIdentifier do
    defstruct [:address]
  end

  defmodule CreateTokenDefinition do
    defstruct [:token_properties, :token_supply, :to_account]
  end

  defmodule TransferTokens do
    # etc
  end

  defstruct [:network_identifier, :at_state_identifier, :actions, :fee_payer, :message, :disable_token_mint_and_burn]  
end

If I do the nested struct route is there a way to convert a nested struct into a nested map so that I can send it as the body of the post request?

If I do the nested struct route is there a way to convert a nested struct into a nested map so that I can send it as the body of the post request?

You’ve got a couple options, if you’re using phoenix it would be conventional to define a render function to drop the struct keys and present the information as needed. Alternatively, if you’re using Jason and tightly coupling your data layer to your presentation layer of you application is an option you could implement the Jason Encoder protocol for your structs.

Map.from_struct, which you can call recursively yourself. But 4 arguments is not excessive IMHO, the stdlib has functions with more than that: Task — Elixir v1.13.2

1 Like

I think what ill do is create a type spec. ill link to the file when im done.

When I have done this for very complicated forms I make sub-structs as described.

I actually use embedded Ecto schemas and write each form section as its own component, probably each disclosure section in your API example would be one component.

The forms act as any other live view form but when they validate successfully I send(self(), {:form_section, %Struct{}}) or send(self(), {:form_section, normalised_params}) to the owning live view, which itself manages whether the whole “form” is submittable or not.

When a form “unvalidates” itself, it send(self(), {:form_section, nil}) which then “unvalidates” the owner too “for free”.

Whether I send a struct or params back depends on the complexity and who I want to own the final shape. If the sub-form section doesn’t match close enough to what I want to store, it’s probably sending params back up the chain instead.

That is to say, the form may ask for dimensions for example, with a unit option, but the main data structure may always store in mm, so the component would work with a %Dimension{value, unit} but send %{value: value_in_mm} back up to the owner. This can keep the validation/processing of unit in the one component and the owner can just trust that the data its getting is already correct.

I think this gives a good balance of coupling and separation, as well pretty easy control over showing parts of a form in a workflow or whatever.

4 Likes