-
-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asynchronous file bootstrap hooks, aka async initFileFn
#329
Conversation
async initFileFn
Can you check if nodejs example still words with this update? https://github.com/flowjs/flow.js/tree/master/samples/Node.js |
At first I was confused what hooks mean and how to use them. Though they are used the same as events, but you can return false in them. Maybe they should be called |
@evilaliv3 Can you review this PR too? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've no particular comments but i just looked at it briefly.
On the name maybe we could call them "Processing hooks" ?
*/ | ||
*filterFileList(fileList, event) { | ||
// ie10+ | ||
var ie10plus = window.navigator.msPointerEnabled; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect this could be completely dropped and simplified. Promises are not supported on IE, even on IE11.
So actually all the specific code related to IE10 could be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's related for every IE/Edge browser, can't test it though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the code is transpiled/polyfilled during compilation phase using core-js.
There is no "supported version" browserlist file but the best validation of the code would be to actually test older browsers which will be possible once the Sauce (or TestingBot) CI is up again (Related to #327 or, if not possible, #325)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one is hard to test, you have to drop an empty folder imo and an empty file to reproduce it. I think it's easier to just leave this line. I can be always updated by IE users later
With #330, it does. |
About the general function prototypes. The new code size is (still) greater than strictly necessary to just have an async
But (1) may be not that significant, and (2) is too prospective or overkill or simply not needed. A least intrusive change would have been to only introduce a I wonder whether you guys would prefer to go a simpler way for now? (I can still reroll that part). |
Async processing should handle every need of a user. So it should be flexible. Anyway, how big is this library? Is it really too much right now? |
|
So it's basically 4x times bigger than it was. Though most projects are already using their own polyfills and for them library size should be the same. Can you calculate library size without polyfills? You could probably compare non-minimized version of original library with non-minimized version of this one. |
Sorry we go off-topic on that PR, but the main problem is that I didn't configured a browserlist in order to selectively polyfill according to a given set of browsers (like Going forward, supported browsers would have to be configured using |
a9a6b82
to
4dc1a3a
Compare
85ebbae
to
e1d4041
Compare
Events in readme files are still listed in camelCase instead of "file-added" |
I'll rebase and fix the README. |
e1a2383
to
31d22d6
Compare
- Sample use `flow.on('file-removed', ({detail: [file]}) => { ... });` | ||
- In an attempt of backward compatibility, some support of camelCase events exist: | ||
``` | ||
flow.on('filesAdded', async (files, event) => { // v2 events prototype |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we should drop this backward compatibility as there is no need to update this package if it already works?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've a project which work with current v3. I'd like to keep it using with either this version with this v3-async patch. Instead of duplicating the callback, I can just rely on the old name and that very convenient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opened flowjs/ngx-flow#70 about ngx-flow.
(I use to rely upon ngx-flow filesSubmitted
which is part of these events changed without backward compatibility)
@@ -146,11 +146,11 @@ export default class extends EventTarget { | |||
*/ | |||
off(event, callback, options) { | |||
if (this.isEvent(event) || !event) { | |||
console.log(`[event] Remove event listeners...`); | |||
// console.log(`[event] Remove event listeners...`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just delete it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry we get back with topic like #312
These debug statements have been tremendously useful for me and I expect that working on this experimental code, these debug statements will keep being useful for some more time.
I'd prefer not have to maintain a debug.patch
and I see no other obvious mean of instrumentation.
(That also why I was so fund of #312)
Great to see this fork going! I think it's almost ready for a merge :)) |
How do you see the future of ngx-flow regarding this? |
@drzraf future of ngx-flow is simple. First let's release this and once this is stable, we can work on ngx-flow |
…ct fix some failures under particular tests sequences
This is a follow-up (and proper implementation) of flowjs#296 (reverted in e867d54) This could be use to initialize a stream, a reader, fetch a remote resource, ... during the FlowFile initialization. `asyncAddFile` and `asyncAddFiles` are introduced which support this mechanism. These function return promises of one (or multiple) FlowFile(s). To implement this: - An AsyncFlowFile class extending a FlowFile is created, overriding the bootstrap part - In order to keep code-duplication low, a filterFileList generator yield files in way common to async and non-async addFiles() functions. The possibly async' nature of initializing file hit back events firing. (flowjs#319) in general and `fileAdded` in particular (flowjs#271) and the current confusión between hooks altering bootstraping and simple events. - fileAdded is now assumed an event. If we detect a return value, a warning is sent. - preFilterFile is introduced and allow filtering the raw file before bootstrap() - postFilterFile is introduced and allow filtering the FlowFile after a (possibly async) bootstrap() - filesAdded is preserved About parameters: - `initFileFn` is only used during bootstrap - If such a helper exists, it's tightly related to addFile* functions. As such, it was deemed adequate to provide it as a parameter to `*addFile*()` (but `opts.initFileFn` is still supported)
Added an Eventizer where all the necessary code exist. Hooks alter code processing and could be `synchronous` or not. Events are CustomEvent dispatched asynchronously for informative purpose.
I'd like to get this merged before working on #346 and rather avoid any merge-conflict. |
sure, merge it |
This is a follow-up (and proper implementation) of #296 (reverted in e867d54)
This could be use to initialize a stream, a reader, fetch a remote resource, ... during the FlowFile initialization.
asyncAddFile
andasyncAddFiles
are introduced which support this mechanism.These functions return promises of one (or multiple) FlowFile(s).
Implement:
filterFileList
generator yield files in way reusable by both async and non-asyncaddFiles()
versions.The possibly async' nature of initializing file hit back events firing (#319) in general and
fileAdded
in particular (#271) and the current confusión between hooks altering bootstraping and simple events.About parameters:
initFileFn
is only used during bootstrapAs such, it was deemed adequate to provide it as a parameter to
*addFile*()
(butopts.initFileFn
is still supported)