byjpr / maprewire Goto Github PK

Release #3 to Hex.pm.

@halostatue, what do you think for version semantics, 0.2.0?

The project could not be analyzed because of maven build errors. Please review the error messages here. Another build will be scheduled within 24 hours. If the build is successful this issue will be closed, otherwise the error message will be updated.

_{This is an automated GitHub Issue created by Sonatype DepShield. GitHub Apps, including DepShield, can be managed from the Developer settings of the repository administrators.}

The current return for map <~> transform is a list [map, remap], but shouldn’t that be a tuple {map, remap}?

• Update readme to represent the changes by @halostatue in PR #3
• Add a contributor table to give credit to the awesome work by @halostatue and other future contributors

Currently MapRewire returns both the original map and the new map. This means we need to create boilerplate to be able to use MapRewire in a pipeline:

  def changeset(variant, params) do
    variant
    |> normalize_data()
    |> cast(
      params,
      ~w(shopify_id title price weight compare_at_price requires_shipping sku available image_id option1 option2 option3)
    )
  end

  defp normalize_data(data) do
    [_old, new] = data <~> @transforms
    new
  end

To reduce the amount of boilerplate needed to use MapRewire we should consider creating a normalize_data function that can be used in a typical changeset:

  def changeset(variant, params) do
    variant
    |> normalize_data(params, @transforms)
    |> cast(
      params,
      ~w(shopify_id title price weight compare_at_price requires_shipping sku available image_id option1 option2 option3)
    )
  end