-
Notifications
You must be signed in to change notification settings - Fork 525
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
Add Syntax Highlighting for SQL Input #373
Conversation
…t I haven't been able to successfully wire up the new component to work with the useForm hook. Once I get that working, I'll take a step back and evaluate if there are any big architectural changes I need to make before using the new SqlTextEditor component in other areas of the app.
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
… take a look at the overall architecture and identify any changes to be made before replacing other text areas with the new SqlTextArea component.
…ad/understand. I created a ternary for the <Field> component in <SegmentForm> and broke out the <Field> component based on if sql was true, instead of trying to do everything in-line with a single <Field> component. The nested ternaries were getting out of hand.
…st so I had record of it if I need to go back to it.
…istingValue'. Also updated the DimensionForm component to consume the new SqlTextArea component.
… placeholder text to use template literals with formatting.
I would love some help testing this to make sure that the The shape of the data being passed to the
Specifically want to confirm that the |
packages/front-end/components/Settings/EditDataSourceSettingsForm.tsx
Outdated
Show resolved
Hide resolved
…ort for javascript, python, yaml, and json. Also made the height adjustable via a prop for future customization.
… updated the standard height of the CodeTextArea component to be 140px instead of 150 as I found other areas in the app referencing 140. Also removed duplicate codeTextAreaHeight props that weren't doing anything since we have a fallback height set.
…he CodeTextArea renders the Field, based on Jeremy's feedback. The Field component was getting really large and complicated.
…found one other sql text area that needed to be refactored to the new component.
{ | ||
ssr: false, | ||
} | ||
); |
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.
Dynamic imports make sense for performance since Ace Editor is so big, but I don't like having to copy/paste this block of code everywhere. Can we move the dynamic import into the CodeTextArea file instead? That way we can just do normal imports throughout the app.
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.
So, I'm trying to simplify things by moving the dynamic import into the CodeTextEditor
so we only have to do it once. But I originally used the dynamic import to resolve an issue other than performance.
Without the dynamic import, upon page refresh, I was getting a window not defined
error that I could only resolve by dynamically importing it.
Now, when I move the dynamic import in to the CodeTextEditor
I'm getting an error of ace is not defined
so I'm working through that now.
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.
Alrighty - just got it working, not sure if I love the implementation, so let me know what you think.
…red out how to move the dynamic import into the CodeTextArea.
maxRows={20} | ||
value={form.watch(`settings.notebookRunQuery`)} | ||
setValue={(sql) => | ||
form.setValue(`settings.notebookRunQuery`, sql) |
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 variable name should not be sql
since it's dealing with python code instead
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.
DOH! Embarrassing. I've updated this. I also realized that line 458 (I'm pretty sure) is not necessary now that I've added the value/setValue props. So I've removed.
… updated EditDataSourceSettings setValue prop.
Empty State
Edit State
This PR handles adding support for the
react-ace
package that enables users to write sql with syntax highlighting.Currently, the implementation only supports SQL, but we can expand that to other languages if needed. Additionally, we can choose between an array of different themes. Currently, the component is consuming the
sqlserver
theme, but that can be easily changed.This update will be reflected in the following places within the app:
To Do:
onValidate
that gets what react-ace callsannotations
. Annotations is an array of errors, that is passed in to theannotations
prop. However, looking at the source code for react-ace,onValidate
only runs inside ofcomponentDidMount
, so its called correctly in our env with the component mounts, but then never gets called again whenever the input changes.I've looked everywhere for a good example of using react-ace with a nextjs app, but haven't been able to. Ace supports live syntax checking using a WebWorker. Perhaps this is where our issue lies - I'll do a little research on WebWorkers to see if that's where our blocker is.
EditDataSourceSettings
component, which has both a SQL textarea and a Python textarea, I'm going to update both, but all other non-sql textareas I will leave for another PR.General Questions:
In the Data Sources -> Edit Query Settings Modal there is a textarea where users can write Python, I can update the SqlTextArea to take in a prop for the language/mode/theme to support Python as well as SQL. Should I do this here or in a separate ticket?Alternatively, we could break the PythonTextArea into it's own component, but there's so much shared between the two it's probably not needed.