Skip to content

feat: enable plugin mechanism for async func #70

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

Merged
merged 22 commits into from
Aug 4, 2022
Merged

feat: enable plugin mechanism for async func #70

merged 22 commits into from
Aug 4, 2022

Conversation

YADROOKIE
Copy link

complete async function plugin
Signed-off-by: yad 459647480@qq.com

Signed-off-by: yad <459647480@qq.com>
@auto-assign auto-assign bot requested a review from webup July 20, 2022 14:28
@mergeable
Copy link

mergeable bot commented Jul 20, 2022

Thanks for creating a pull request! A maintainer will review your changes shortly. Please don't be discouraged if it takes a while.

@webup webup changed the title ✨ feat: enable asycn function plugin feat: enable asycn function plugin Jul 20, 2022
@webup webup linked an issue Jul 20, 2022 that may be closed by this pull request
@webup webup added the type: feature New feature or request label Jul 20, 2022
@YADROOKIE YADROOKIE marked this pull request as draft July 20, 2022 14:50
Copy link
Collaborator

@webup webup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems there would be some structural level code refactoring, so let me put all my comments at below trying to give you a whole picture.

Below items are listed in priority, from the most to least important.

  1. Where comes the PLUGIN_CONTEXT?

    • Taking context_test.go for reference, all of the context data are stored in FUNC_CONTEXT.
    • Accordingly, plugin_cotext.ts is NO need to exist, changes in options.ts is redundant, simply adding some plugin related fields in OpenFunctionCotext is good enough. (Check Context structure in plugin mechanism for reference as well)
    • Nevertheless, we need some Plugin class to deal with plugin instance so as to hold data and provide instance methods like get shown in this demo.
  2. How to store plugins?

    • A map structure is already an good structure to hold and access both plugin name as key and function instance as value, so why we have to need prePlugins / prePluginFuncs and the like to hold keys and values separately?
    • BTW, in ts, Record is a more standard type to hold objects, rather than Map.
  3. Try to take more advantage of well-known Node.js libraries

    • console.error should be replaced by debug (could search usage in files)
    • for (let) loop should be replaced by Lodash collection utilities which will help ensure the safe execution and returns
  4. Finally, pay a little attention to import sequence, usually we group imports from the same level together, and common sequence is the farther the earlier. For example, node built-in libs -> 3rd-party libs -> files in grandparent folder -> files in parent folder -> side-by-side files, etc.

@YADROOKIE
Copy link
Author

I got it , prePlugins & postPlugin is in order to ensure execution sequence

image
image

@webup
Copy link
Collaborator

webup commented Jul 21, 2022

I got it , prePlugins & postPlugin is in order to ensure execution sequence

image image

So you might use a collection of plugin objects for "pre & post" separately to keep the sequence with plugin data encapsulated into a class object.

@YADROOKIE YADROOKIE requested a review from webup July 22, 2022 08:47
@YADROOKIE YADROOKIE marked this pull request as ready for review July 22, 2022 09:05
@YADROOKIE YADROOKIE marked this pull request as draft July 22, 2022 09:05
@YADROOKIE
Copy link
Author

Im refactor code, but lodash collection utilities is aysnc ,so I still use for loop to ensure plugin hook sync ;

@webup
Copy link
Collaborator

webup commented Jul 22, 2022

Im refactor code, but lodash collection utilities is aysnc ,so I still use for loop to ensure plugin hook sync ;

Oh, you are right, may try await array.reduce to keep the sequence, for example.

Signed-off-by: yad <459647480@qq.com>
Signed-off-by: yad <459647480@qq.com>
@YADROOKIE YADROOKIE marked this pull request as ready for review July 23, 2022 08:59
@auto-assign auto-assign bot requested a review from benjaminhuo July 23, 2022 08:59
@YADROOKIE YADROOKIE marked this pull request as draft July 23, 2022 08:59
@YADROOKIE
Copy link
Author

improve the code & add unit test

Copy link
Collaborator

@webup webup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@YADROOKIE I'm thinking why shouldn't we fallback all methods for a user plugin function, so that no need to do lots of fields & methods checking?

It looks better to attach default get / execXXX methods to plugin function prototype instead rudely telling user you must have blablabla otherwise your function wouldn't work. What do you think? :)

src/loader.ts Outdated
@@ -92,6 +95,7 @@ export async function getUserFunction(
} | null> {
try {
const functionModulePath = getFunctionModulePath(codeLocation);
console.log(functionModulePath);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't forget to remove console.log, or use debug instead.

src/options.ts Outdated
@@ -134,7 +134,6 @@ const FunctionContextOption = new ConfigurableOption(
}
}
);

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why remove this line?

src/loader.ts Outdated
if (
options.context &&
options.context.prePlugins &&
options.context.postPlugins
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Take better advantage of optional chaining, i.e. options.context?.postPlugins
  2. Why we should ensure both pre and post plugins existed? Seems it's better to make another helper function to encapsulate common logics and handle pre and post plugins separately.

src/loader.ts Outdated
options.context.prePlugins &&
options.context.postPlugins
) {
options.context.prePlugins.forEach(item => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in our last call, use lodash utilities instead to ensure safe invocation and returns.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use plugin instead of item, that's more meaningful.

src/loader.ts Outdated

try {
// load plugin js files
const instances: Map<string, Plugin> = new Map();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not simply using {} instead of Map?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can clear type

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can clear type

So why not using Record?

static Name = "error-miss-get-plugin"

execPreHook(ctx){
console.log(`-----------error plugin pre hook-----------`)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make sure or indent contains only 2 spaces.

@@ -0,0 +1,33 @@
const { resolve } = require("path")
Copy link
Collaborator

@webup webup Jul 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use import instead of require, let's keep the same coding style.

constructor(){
console.log(`init demo plugins`)
}
sleep(){
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better to make it as a helper function out of the class.

async execPreHook(ctx){
console.log(`-----------demo plugin pre hook-----------`)
ctx['pre'] = 'pre-exec';
await this.sleep()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please ensure all sentences in the project ends with a semicolon.

import {FrameworkOptions} from '../../src/options';
import assert = require('assert');

const TEST_CONTEXT: OpenFunctionContext = {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Too much alike with async_server, it's better to combine the test cases to make better use of the common data and logics.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At first I was combine the test cases with async_server ,but it will conflict make it single file finally

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, it's better to extract common test data into a separate file for reuse.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it seem still have conflict in when data in a common file

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it seem still have conflict in when data in a common file

Please describe the problem or details, it's hard to provide help based on "it seems".

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was in the wrong position before , it is ok now

Signed-off-by: yad <459647480@qq.com>
@YADROOKIE YADROOKIE requested a review from webup July 25, 2022 11:44
Signed-off-by: yad <459647480@qq.com>
…d replace Map

Signed-off-by: yad <459647480@qq.com>
Signed-off-by: yad <459647480@qq.com>
@YADROOKIE YADROOKIE marked this pull request as ready for review July 26, 2022 02:32
@YADROOKIE YADROOKIE marked this pull request as draft July 26, 2022 02:32
@YADROOKIE YADROOKIE marked this pull request as ready for review August 3, 2022 11:08
@YADROOKIE YADROOKIE marked this pull request as draft August 3, 2022 11:08
@YADROOKIE YADROOKIE marked this pull request as ready for review August 3, 2022 23:05
Copy link
Collaborator

@webup webup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally speaking, problems addressed in the latest review have been resolved, so it's okay to make a merge.

Signed-off-by: yad <459647480@qq.com>
@webup webup changed the title feat: enable asycn function plugin feat: enable async function plugin Aug 4, 2022
@webup webup changed the title feat: enable async function plugin ✨ feat: enable plugin mechanism for async func Aug 4, 2022
@webup webup merged commit 5d91417 into OpenFunction:master Aug 4, 2022
@webup
Copy link
Collaborator

webup commented Aug 4, 2022

@all-contributors please add @YADROOKIE for code contribution

@allcontributors
Copy link

@webup

I've put up a pull request to add @YADROOKIE! 🎉

@webup webup changed the title ✨ feat: enable plugin mechanism for async func feat: enable plugin mechanism for async func Aug 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Enable function plugin mechanism
2 participants