after connect invoke onData twice

[sixinyiyu]

I want to know the life cycle of pipy ,

.listen(6081)
  .onSessionStart(
    () => (
      console.log('6081session start')
    )
  )
  .connect('127.0.0.1:6080')
  .onData(
    () => (
      _queue.push(Date.now() + 6081),
      console.log('0681 onData', JSON.stringify(_queue))
    )
  )

out put

2021-06-22 11:09:59 [info] [pjs] 6080 session end [1624331405455]
2021-06-22 11:09:59 [info] [pjs] 0681 onData [1624331405455,1624331405456]
2021-06-22 11:09:59 [info] [pjs] 0681 onData [1624331405455,1624331405456,1624331405456]

[pajama-coder]

This is the expected behavior. The second onData event will be a zero-length data chunk, which is acting as a "flush" event. This is necessary since some filters have inherent buffering, such as connect, and they would buffer data up to the point of flushing to reduce the number of underlying syscalls for improved performance.

Thanks for bringing up the issue tho.

[pajama-coder]

This got me thinking that all those onXXX filters could be a bit misleading sometimes. We've got questions from other people as well about when an onXXX would get called, their invocation order, etc. The answer is actually very simple but somehow surprising, they are, just like all other filters, called in the order they are written. We are looking to see if things could be more understandable if we rename onXXX as handleXXX so that people won't confuse it with other event-driven systems.

[sixinyiyu]

This got me thinking that all those onXXX filters could be a bit misleading sometimes. We've got questions from other people as well about when an onXXX would get called, their invocation order, etc. The answer is actually very simple but somehow surprising, they are, just like all other filters, called in the order they are written. We are looking to see if things could be more understandable if we rename onXXX as handleXXX so that people won't confuse it with other event-driven systems.

See the name and know the meaning， I can't agree any more。