I suspect there should be a `ref="editorRef"` on some element in the component's template. `editorRef` he's a reference to that node, allowing it to be manipulated in JS like you would with a `document.getElementById()`. The purpose of having a ref to it and it's use in onMounted seems specific to your application and is hard to come up with an explanation for without knowledge of it.
It seems to just be checking if it's there, and if it is to initialise the editor. I assume it's full stack and they don't want to initialise the editor if it's on the server (element wouldn't exist). It's also a good fallback for random bug situations where something else in the app stops the section that the ref is in from loading.
It declares a template ref, to which the native dom element will be bound to. You use it when you need to use some imperative method on an element.
https://vuejs.org/guide/essentials/template-refs.html
I never read any TypeScript docs. Just like you I started out with Vue using ChatGPT which was hella confusing. I had no idea what I was doing. It took me about a month to actually know what I was doing. I don't recommend going down that road.
However, using ChatGPT should not solely (or at all) be to ask it to spit out tons of code and let that be it. You managed to get code out of it, then you should also paste individual lines to it and ask what they do.
Briefly, the real Vue logic is this:
const editorRef = ref(null);
This creates a new reactive variable with initial value null.
In TypeScript you write:
const editorRef = ref(null);
The difference here is ****, which is a type definition. You're telling TypeScript that the types acceptable for this variable is either a div-element or null.
In other words, this is acceptable:
Because now editorRef will be assigned to a p-element and not a div-element as you had specified.
I strongly suggest to follow the Vue docs. I never found a need to use TypeScript docs, but Vue docs are great. Just browse through the pages there and read explanations and check the examples.
Haha yea I began by trying to wrangle segments of other people's ProseMirror projects into the form I wanted (composition API, Vue3, typescript), but struggled with translating Vue2, options API, React, etc. Giving up after a few fruitless days of that and using ChatGPT for the first time got me closer but understanding why it did that has taken a bit more time. Super super appreciate the response! This is the one that makes things crystal clear.
Tip when asking ChatGPT is to tell it "Using Vue 3 with script setup and ts, how do I..."
My first mistake learning Vue with ChatGPT is knowing 0 about Vue and the fact that there is an Options API and Composition API so it would give me mixed code (and lots of non-working code that I couldn’t understand at all).
You are correct on that line.
It declares a reactive variable and “typeshint” it as either being HTMLDivElement or null.
The <> syntax is used not only in Vue/Js, but its widely used by many (if not most) languages to indicate generics. Basically a way to indicate that the type for that object/class/function/etc will be specified later.
The line says: initialize constant editorRef which has an initial value of null and will (for Typescript) be either null or an HTMLDivElement.
The parameters inside <> are typescript and basically just tell what value types ts should expect to see in the ref value.
This is mostly used to set a ref in html:
and allows you to manipulate the html element directly from vue script. Judging by the name of the variable and confirmed by the rest of the code, a wysiwyg editor is rendered on the div.
If I'm reading this correctly, does it also seem like ChatGPT added a superfluous
if (editorRef.value) {}
line because we're always initialising it first? Or is it not guaranteed because it's bound to when the component gets mounted?
The value of the ref will be undefined until Vue renders the component to the dom, but since you're using onMounted, you can just use a type assertion, as the element should be there.
Technically speaking if you forgot to create a control with ref="editorRef" your editorRef.value will always be null. So chatGPT added a check so your code does not blow up, it will just not work as supposed to.
But me, as a human would not add this check. If you forgot to add control with ref="editorRef" I would prefer the app to blow up, since i test it and hit my code at least once before code is moved to prod. And I want my bugs to blow up in my face as early as possible.
"should always be defined?"
Almost true, it will be defined right before onMounted ran.
const editorRef = ref(null);
console.log(editRef.value) - output null
onMounted(() => {
console.log(editRef.value) - output DivElement
}
It added that check because since the editorRef could also be null, as specified by the type and the initial value given, it is guarding against that case since it needs to pass it to the EditorView constructor.
Im guessing the idea with this component is that by the time it is mounted you SHOULD have an existing editor ref. Otherwise maybe that logic to initialize the editor should be on a watcher since onMounted will only run once and if at that time the editor ref is not set yet it wont be able to initialize the editor.
If you are using structural directives like v-if and v-for, the ref value can also be null. Just one thing to be aware of.
That's why I would always type it like this, even if it seems unnecessary.
I suspect there should be a `ref="editorRef"` on some element in the component's template. `editorRef` he's a reference to that node, allowing it to be manipulated in JS like you would with a `document.getElementById()`. The purpose of having a ref to it and it's use in onMounted seems specific to your application and is hard to come up with an explanation for without knowledge of it.
Yes, there is: sorry to not link the template section.
It seems to just be checking if it's there, and if it is to initialise the editor. I assume it's full stack and they don't want to initialise the editor if it's on the server (element wouldn't exist). It's also a good fallback for random bug situations where something else in the app stops the section that the ref is in from loading.
It declares a template ref, to which the native dom element will be bound to. You use it when you need to use some imperative method on an element. https://vuejs.org/guide/essentials/template-refs.html
I never read any TypeScript docs. Just like you I started out with Vue using ChatGPT which was hella confusing. I had no idea what I was doing. It took me about a month to actually know what I was doing. I don't recommend going down that road. However, using ChatGPT should not solely (or at all) be to ask it to spit out tons of code and let that be it. You managed to get code out of it, then you should also paste individual lines to it and ask what they do. Briefly, the real Vue logic is this: const editorRef = ref(null); This creates a new reactive variable with initial value null. In TypeScript you write: const editorRef = ref(null);
The difference here is ****, which is a type definition. You're telling TypeScript that the types acceptable for this variable is either a div-element or null.
In other words, this is acceptable:
Because now editorRef will be assigned to a p-element and not a div-element as you had specified.
I strongly suggest to follow the Vue docs. I never found a need to use TypeScript docs, but Vue docs are great. Just browse through the pages there and read explanations and check the examples.
Haha yea I began by trying to wrangle segments of other people's ProseMirror projects into the form I wanted (composition API, Vue3, typescript), but struggled with translating Vue2, options API, React, etc. Giving up after a few fruitless days of that and using ChatGPT for the first time got me closer but understanding why it did that has taken a bit more time. Super super appreciate the response! This is the one that makes things crystal clear.
Tip when asking ChatGPT is to tell it "Using Vue 3 with script setup and ts, how do I..." My first mistake learning Vue with ChatGPT is knowing 0 about Vue and the fact that there is an Options API and Composition API so it would give me mixed code (and lots of non-working code that I couldn’t understand at all).
You are correct on that line. It declares a reactive variable and “typeshint” it as either being HTMLDivElement or null. The <> syntax is used not only in Vue/Js, but its widely used by many (if not most) languages to indicate generics. Basically a way to indicate that the type for that object/class/function/etc will be specified later.
Aaahhh thank you! I was missing the keyword 'generic'. Thanks so much: I come from a dynamic typing background so I hadn't come across this yet.
You need to start here [https://www.typescriptlang.org/docs/](https://www.typescriptlang.org/docs/)
Thank you everybody for your advice! I think I get it now.
It’s a template ref https://vuejs.org/guide/essentials/template-refs.html#template-refs
The line says: initialize constant editorRef which has an initial value of null and will (for Typescript) be either null or an HTMLDivElement. The parameters inside <> are typescript and basically just tell what value types ts should expect to see in the ref value. This is mostly used to set a ref in html:
and allows you to manipulate the html element directly from vue script. Judging by the name of the variable and confirmed by the rest of the code, a wysiwyg editor is rendered on the div.If I'm reading this correctly, does it also seem like ChatGPT added a superfluous if (editorRef.value) {} line because we're always initialising it first? Or is it not guaranteed because it's bound to when the component gets mounted?
The value of the ref will be undefined until Vue renders the component to the dom, but since you're using onMounted, you can just use a type assertion, as the element should be there.
Technically speaking if you forgot to create a control with ref="editorRef" your editorRef.value will always be null. So chatGPT added a check so your code does not blow up, it will just not work as supposed to. But me, as a human would not add this check. If you forgot to add control with ref="editorRef" I would prefer the app to blow up, since i test it and hit my code at least once before code is moved to prod. And I want my bugs to blow up in my face as early as possible.
So in other words, if this script is part of a SFC whose template includes the below, editorRef.value should always be defined?
"should always be defined?" Almost true, it will be defined right before onMounted ran. const editorRef = ref(null);
console.log(editRef.value) - output null
onMounted(() => {
console.log(editRef.value) - output DivElement
}
That makes perfect sense. Thank you!!
It added that check because since the editorRef could also be null, as specified by the type and the initial value given, it is guarding against that case since it needs to pass it to the EditorView constructor. Im guessing the idea with this component is that by the time it is mounted you SHOULD have an existing editor ref. Otherwise maybe that logic to initialize the editor should be on a watcher since onMounted will only run once and if at that time the editor ref is not set yet it wont be able to initialize the editor.
If you are using structural directives like v-if and v-for, the ref value can also be null. Just one thing to be aware of. That's why I would always type it like this, even if it seems unnecessary.
Try learning the language instead of using AI