explicit signals connect in view package

I don’t like that we expose all signals to each cerebral connected component. Also we can’t use constants to define signal path. Here is proposal:

connect({
  foo: 'some.state.path',                // exist
  bar: props => `some.entity.${byKey}`,  // exist
  baz: Computed(),                       // exist
  signals: {                             // proposal
    smthHappened: 'path.to.smthHappened'
  }
}, function Component ({ foo, bar, baz, signals }) {
  return (
    <div>
      <li>{foo}</li>
      <li>{bar}</li>
      <li>{baz}</li>
      <button onClick={e => signals.smthHappened()}>
    </div>
  )
})

or

connect({
  foo: 'some.state.path',                // exist
  bar: props => `some.entity.${byKey}`,  // exist
  baz: Computed(),                       // exist
}, {                                     // proposal
  smthHappened: 'path.to.smthHappened'
}, function Component ({ foo, bar, baz, smthHappened }) {
  return (
    <div>
      <li>{foo}</li>
      <li>{bar}</li>
      <li>{baz}</li>
      <button onClick={e => smthHappened()}>
    </div>
  )
})

[christianalfoni]

I think we are taking way too much freedom on that one 😃 Technically we need to extract signals specifically… so I still favor:

connect({
  foo: 'some.state.path',                // exist
  bar: props => `some.entity.${byKey}`,  // exist
  baz: Computed(),                       // exist
}, {                                     // proposal
  smthHappened: 'path.to.smthHappened'
}, function Component ({ foo, bar, baz, smthHappened }) {
  return (
    <div>
      <li>{foo}</li>
      <li>{bar}</li>
      <li>{baz}</li>
      <button onClick={e => smthHappened()}>
    </div>
  )
})

And it reads very well:

1. What state deps has this component
2. What signals does this component use
3. The component

It is also similar to connect by Redux:

1. State
2. Actions
3. Component

[christianalfoni]

Hehe, I have a tendency to stretch my opinions as far as I can 😉

But I still think namespaced is the wrong way to go. When we compare the two approaches there are more negatives on the state/signals namespace approach than extending with a second argument:

namespace negatives

• We change current api
• If you write state/signals wrong it will not work
• To support both old and new api we have to create special temporary code that is prone for bugs
• With components that does not use signals we are increasing syntax
• There will never be more than state/signals put into components so it is weird to have only two static properties on an object. Objects are suited for dynamic properties
• We force nested destructuring, which is more syntax again and harder to read

extra argument negatives

• I can not find any negatives? 😃