debug parameter for sample

[NazariiShvets]

Proposal

debug parameter for sample to add more insights for debugging

Precondition:
Something wrong with beautifull sample like:

sample({
  clock: [event1, $count]
  source: { foo: $foo, bar: $bar }
  filter: and($enabled, not($pending)),
  target: startFx
})

To debug values then clock is triggered it requires rewriting it in different way:

1. extracting filter into source
2. Adding filter as handler + console.log there
3. Adding fn to remove new unwanted paramethers (bcs filter moved to source)
4. add clock and target to patronum.debug
5. After debuging you rewrite it back to original form

patronum.debug(event1, $count, startFx);

sample({
  clock: [event1, $count],
  source: { foo: $foo, bar: $bar, enabled: $enabled, pending: $pending},
  filter: (source) => {
     console.log('[source]', source);
     const filter = source.enabled && !source.pending;
     console.log('[filter]', filter);
     return filter
  }
  fn: ({ enabled, pending ,...params }) => {
     console.log('[fn]': params);
     reutrn  params
  }
  target: startFx
})

Use case

Adding debug will look as this:

sample({
  clock: [event1, $count]
  source: { foo: $foo, bar: $bar }
  filter: and($enabled, not($pending)),
  target: startFx,
  
  debug: true
})

And in console i expect to see something like this

- group (sample)
  - [clock] (event1): `param`
  - [source]: `value`
  - [filter]: ( passed/not passed ): `returned value`
  - [fn]: `(clock, source)` -> `result`
  - [target]: called with `result`
- group end (sample)

[zerobias]

The goal you wanted looks interesting, my main concern is that debug code should be implemented by sample, which is way less than optimal. May be this should work through effector/inspect?

[NazariiShvets]

Agree on that. Implementation is not goal, goal is this precious info in grouped logs.

It be suited better to log into inspect rather directly writing to console. Also inspect api could be used as single place for custom logic. Yea that make more sense.

I guess it would be better to have some kind of meta info, so u can filter(custom logic in inspect) rest of logs and only show necessary info

[NazariiShvets]

Also, mb debug parameter can have some overloads, like true | { name: 'custom-name-to-differentiate-logs' } and put it into meta for inspect api, to handle fancy ways to log that info

[zerobias]

Sounds reasonable, if no one on the team has any other complaints, we'll try to implement it