feat: add computation field

[islxyqwe]

Make user able to add a computed field with sql.
need to use with a computation service that use sql.
usage:
<GraphicWalker {...props} experimentalFeatures={{computedField: true}} />

more info:
https://github.com/Kanaries/graphic-walker/wiki/How-to-Create-Computed-field-in-Graphic-Walker

more features:

aggergated fields will show gray and be disabled when "Aggergation" is off.

you can filter at non-aggergation computed fields.

in the data board, you can check the value of any row with your non-aggergation computed fields.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
graphic-walker	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 9, 2024 0:52am

[github-actions]

Risk Level 2 - /home/runner/work/graphic-walker/graphic-walker/packages/graphic-walker/src/lib/vega.ts

The code seems to be well written and follows the SOLID principles. However, there are a few areas that could be improved for better readability and maintainability:

1. The function toVegaSpec has a lot of parameters. Consider using a parameter object to make the function signature more manageable and improve readability.

2. There are several instances where the ternary operator is used in a complex way, which can make the code harder to read. Consider simplifying these expressions or breaking them down into multiple steps.

3. The guard function is used multiple times with the same parameters. Consider storing the result in a variable to avoid unnecessary function calls.

Here's an example of how you could implement these suggestions:

const guardResult = guard(rowsRaw);
const rows = guardResult.filter((x) => x !== NULL_FIELD);

4. The spec object is being mutated in several places. This can lead to bugs and makes the code harder to reason about. Consider using a more functional style of programming, where you avoid mutating objects.

---

Risk Level 2 - /home/runner/work/graphic-walker/graphic-walker/packages/graphic-walker/src/fields/datasetFields/utils.ts

The code changes seem to be adding new functionality and modifying existing ones. There are no apparent bugs or performance issues. However, the readability of the code could be improved. The function useMenuActions is quite long and complex. It would be beneficial to break it down into smaller, more manageable functions. This would make the code easier to understand and maintain. Also, consider adding comments to explain what each part of the function does.

---

Risk Level 3 - /home/runner/work/graphic-walker/graphic-walker/packages/graphic-walker/src/lib/execExp.ts

The code is generally well written, but there are a few areas that could be improved:

1. In the execExpression function, there is a switch statement inside a for loop. This could potentially be refactored to improve performance and readability. Consider creating a map of functions for each case and then just calling the appropriate function based on param.type.

2. In the execSQL function, there is a check for param.type === 'sql'. If it's not 'sql', the function returns the original data. This could potentially lead to silent failures if the function is called with an incorrect param type. Consider throwing an error or at least logging a warning in this case.

3. The execSQL function also checks if result is an array and throws an error if it is. This is good error handling, but the error message could be more descriptive. Consider including the mea.field in the error message to make it easier to debug.

---

📚🔧🔍

---

Powered by Code Review GPT