Conversation
| end | ||
|
|
||
| def add(access_token:, xero_tenant_id:, job:) | ||
| validated_job = XpmRuby::Schema::Job::Add[job] |
There was a problem hiding this comment.
Wonder how we could drop all the :: operations? Maybe something like:
# lib/xpm_ruby/job.rb
require_relative "job/add_schema"
module XpmRuby
module Job
def add(...)
validated_job = AddSchema[job]
end
end
end
There was a problem hiding this comment.
Hmm, I will have a think about it. I was following the structure from the client success gem. I think if we keep them in the same relative place in all our gems it might make it easier for our devs to work across gems.
But then again I am not 100% why the client success gem was structured this way.
;)
There was a problem hiding this comment.
I suppose one argument for a dedicated schema directory is that theoretically a data structure could be independent of the actions? So xpm_ruby/job.rb is a module containing job related functions, but it is not a class per se. Theoretically any module could access any schema (so one of the calls on client, might use the job schema).
There was a problem hiding this comment.
I will merge this for now, we can always move it later (pending a discussion).
* Add dry types gem and Job::Add schema * Add function and test for add job * use string keys instead of symbol keys
* Add dry types gem and Job::Add schema * Add function and test for add job * use string keys instead of symbol keys
2 participants
We are adding the Dry Types gem to put some type checking onto the job hash used when adding a job.
This will help us surface type errors to the gem users when they are sending data over to the XPM Api for processing (which will in turn help with error checking and validation).
More info on Dry Types and hashes can be found here.
https://dry-rb.org/gems/dry-types/1.2/hash-schemas/