Allow anonymous_id in alias and group

[rohitpaulk]

Fixes #181.

This PR refactors the handling of common fields, extracts a FieldParser that adheres to the Segment spec.

This will result in the following behaviour changes:

• alias will now accept anonymous_id
• group will now accept anonymous_id
• page will now validate that name is non-empty

As I refactored this to adhere to the Segment spec, I found a couple of deviations from the spec:

• options is accepted in every call, but not mentioned in the spec
• screen takes a category parameter, which is not mentioned in the spec

I've retained these for backwards compatibility.

[f2prateek]

options is mostly a convenience for the library to accept common fields (so that each declaration doesn't have to have a massive list for integrations, context, timestamp, etc.)

[codecov-io]

Codecov Report

Merging #188 into master will increase coverage by 0.67%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #188      +/-   ##
==========================================
+ Coverage   98.37%   99.04%   +0.67%     
==========================================
  Files          10       11       +1     
  Lines         430      419      -11     
==========================================
- Hits          423      415       -8     
+ Misses          7        4       -3

Impacted Files	Coverage Δ
lib/segment/analytics.rb	95.23% <100%> (+0.23%)	⬆️
lib/segment/analytics/client.rb	100% <100%> (+2.05%)	⬆️
lib/segment/analytics/field_parser.rb	100% <100%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cfc197d...e2336c2. Read the comment docs.

[rohitpaulk]

options is mostly a convenience for the library to accept common fields (so that each declaration doesn't have to have a massive list for integrations, context, timestamp, etc.)

Ah, okay. What is the intended usage here?

Is this:

client.track(event: "something", context: { a: "b" })

the same as this?

client.track(event: "something", options: { context: { a: "b" } })

[rohitpaulk]

#188 (comment)

@f2prateek reminder, there's an open question here 🙂

[f2prateek]

@rohitpaulk ah missed this. correct, they should be considered similar. I would prefer if the library provided only one way for this though (rather than offering both)!

What's more natural for Ruby developers to use?

[rohitpaulk]

What's more natural for Ruby developers to use?

The natural way is to have different top-level keys for each parameter. i.e.

client.track(event: "something", context: { a: "b" })

rather than:

client.track(event: "something", options: { context: { a: "b" } })

I'm going to merge this PR as it retains backward compatibility. If we agree that options should be removed, I'll work on a deprecation notice that we can then remove in a minor release.