edisonywh / condiment Goto Github PK

Right now I am testing it on a real production app with slickinbox.com, and I realised that sometimes if a user writes the query wrongly, the error message currently isn't very helpful (it exposes internals of Condiment, liek Keyword.keys fails etc).

One idea is to to wrap all Condiment code in a try/catch, and raise an obvious CondimentError, that details which step it fails on, and what error it's wrapping.

Might be nice to be able to do a dry run on a Condiment struct, this could be useful for testing and also useful for debugging to see what is going to be run (without actually running).

Some considerations:

• What's the API? Do we add opts to Condiment.run?
• What should this API return? One useful example is how Ecto.Multi does to_list/1

Right now most of the usage/examples are focusing on list_* or get_*, which works fine, but it might be interesting to see if Condiment can handle update_* too.

From my experience, update tend to look a bit more complicated, so I'm not sure if the use case fits perfectly, but I'm happy to see what you can suggest.

This requires a bit more comment & discussions, but it could be nice to have an API to always run Condiment step, even if the opts are not being passed in.

For example:

Condiment.new([])
|> Condiment.add(:step, fn x, y -> IO.inspect(x) end)
|> Condiment.run()

Right now this won't run :step, because the user requested field is empty. However, it might be useful to have a switch to always run it, so one example is to maybe add a new opts to Condiment.add/4, so the usage looks like this:

Condiment.new([])
|> Condiment.add(:step, fn x, y -> IO.inspect(x) end, run: true)
|> Condiment.run()

with run: true, then it will always run, and run: false it'll always skip.

Why?

It could be useful in situation where you always need to preload some associations for example (though that can done now with default query).

It could also be useful in a feature-flag environment, so that you can hook into your feature flag management

Condiment.new([])
|> Condiment.add(:step, fn x, y -> IO.inspect(x) end, run: FeatureFlag.active?(:new_api))
|> Condiment.run()

Another possibility is to generalize it to take multiple booleans, like gates. For example:

Condiment.new([])
|> Condiment.add(:step, fn x, y -> IO.inspect(x) end, gates: [RateLimit.check(user), FeatureFlag.active?(:new_api)])
|> Condiment.run()

This adds a list of gates, and if everything in gates evaluate to true, then we run it. If you want to always run something then, just do gates: [true], or gates: [false]

Still, I don't see much point in adding it if there's no obvious use cases in the wild, so if you run into this, comment below and let us know