I was reading answers to a Stack Overflow question when I came across this one, which has the file names in its example code ending in .view.
My experience with Vue has been that the single-file components always have their filenames end in .vue.
I looked online and couldn't find any other references to the .view extension.
Is there such a thing as a .view file in Vue? Or was this more likely a typo?
Considering the fact that the user who posted the answer has apparently no knowledge in Vue (or frontend), I assume this is quite a typo indeed.
There is no such thing in Vue. Especially since the answer is using script setup, which is quite specific to Vue, since it's some sugar syntax.
I've edited his answer to fix the typo.
I have notified the answerer of it, he may come back here at some point if he founds out that my edit was wrong.
Vue comes from View, and Vue is the french word for it. The confusion is understandable but there is no such things as .view.
There are no other tags like Laravel, Ruby on Rails or alike, so 100% a typo.
Related
as shown below:
I don't understand why, the syntax and format is correct, it's extremely confusing.
I review my code carefully but can't figure out
this seems to be a bug with VS Code. This could be because VS Code is not updated, or an extension that is not supported anymore.
first, try ctrl + shift + p and running >Developer: Reload Window this should reload your current environment and the error should be fixed.
If that doesn't work, try a different extension. I currently use Vetur, and Prettier.
And don't forget to make sure your VS Code is up to date. go to the bottom left and click the settings cog, then check for update or updates.
My answer is, "Start from scratch, and record your steps." I'm happy to share my notes on what is presently working: https://github.com/TheAutomaTom/VsCodeSettings-Vue3
My personal machine had been in that spot for some weeks, so I took a step back and dump out your cornucopia of extensions and their dependencies.
Only run pertinent language services. This is a tall order given how much a Vue + Typescript + Tailwind on Vite app covers. I am suspicious of generalized HTML/CSS/JS packs though, because they may not be built to parse Vue SFCs. Every new release of a services intended for other frameworks, like Angular or React, are still possible culprits (and moving targets).
I gave up getting Prettier and ESLint on stable ground. For a non-workplace thing, I feel okay about that. You may be having issues with a global package, if you've been experimenting. I've tossed out a couple branches following different tutorials. I intend to revisit this one since it has some example projects: rvest.vs-code-prettier-eslint
I've noticed the Volar team seems to let oddities squeak out a little more frequently than I remember in Vetur.... but we love them just the way they are. Sometimes I downgrade just to check if I've gone crazy, yet.
I started using react-i18next a few days ago and I am very satisfied with it. However, I've been seeing this 'cimode' language here and there, in some posts and while debugging, but have no clue what it means. I've searched all over, I believe, and can't find any documentation on it.
In my particular case, I am generating some boilerplate code in a new website and created a demo page to show how to use localization in the website. I am generating toggle language buttons from the languages I set on the whitelist and, to my surprise, I have a 'cimode' button. I know I can filter it out and I will, but I would like to know what it should be used for and maybe to see better documentation for it in https://react.i18next.com/.
From my understanding, CIMODE is used for testing to consistently return the translation key instead of the variant value.
It seems rather hidden on the FAQ.
I find, even when assigning the decorator #singleton(false) to the view-model, that while the view-model does then persist as a singleton across activation/deactivation, the bindings and components, etc do not.
(I assume this is because they are stored in a container that is disposed on deactivation.)
The result is that upon every deactivation/activation of a view with a singleton view-model, the view is un-bound and then re-bound.
Is it possible to cause the bindings to persist across deactivation/activation?
This one stumped me for a good while. It also confused me as to why implementing it was not a higher priority for the Aurelia Team.
This takes a fair amount of code to get working. I have put the code in a Gist here: https://gist.github.com/Vaccano/1e862b9318f4f0a9a8e1176ff4fb727e
All the files are new ones except the last, which is a modification to your main.ts file. Also, all my code is in Typescript. If you are using Javascript you will have to translate it.
The basic idea behind it is that you cache the view and the view model. And your replace the router with a caching router. So when the user navigates back to your page, it checks first to see if there is a view/view model already created and uses that instead of making a new one.
NOTE: This is not "component" level code. That means I have tested that this works for the scenario that I use it for.
I got my start for making this change here: https://github.com/aurelia/router/issues/173 There is another user (Scapal) made something that works for him and posted it there. If what I am posting does not work for you, his may help you out.
i'm also interested in an answer to this.
maybe i'm now making a complete fool out of me but why not use aurelia-history navigate(..) command?
I'm trying to get DOH testing working for my company's upcoming platform, but I can't figure out the right combination of paths. Our file structure looks like this:
/dojo15
/release
/dojo
/dojo
dojo.js
dojoExt.js
/dojo
dojo.js
/util
/doh
/js
mainLib.js
/tests
base.js
This was created by our contractors, so unfortunately there are some things I have to figure out as I'm going along.
The "release" directory is what is used on our pages.
The "util" directory doesn't exist in our release directory. (I'd like to avoid having to make a copy of it there.)
I'm not entirely sure what they did with dojoExt.js there, but it seems to be required. I was able to make a simple "hello world" sort of test, but once I did dojo.require(js.mainLib), I got an error that dojo.behavior.add is not a method. So it seems to be they made a stripped-down dojo.js and put other required code in dojoExt.js.
My guess is that DOH is using the dojo in dojo15/dojo, but I need to include dojo15/release/dojo/dojo/dojoExt.js. I've tried every combination of dojoUrl, testModule, registerModulePath I can think of...also saw "boot" and "path" from other SE questions, even though I can't see in runner.html where they would even be used, but I tried throwing them in to see if they'd magically help anyway.
At the moment I don't really have the option to move code around, so I'm hoping to work this out with files where they currently are.
Did you try the bits I suggested over at a related question? We use the bits I detailed there to pull together a completely custom layout of dojo + util. Take a look at both boot and dojoUrl. I think it's runner.js that does most of the cunning stuff, rather than runner.html.
Is the problem that you can't arrange for dojoExt.js to get loaded? How does your other code arrange for it to get loaded? Is tests/base.js your test module?
Can anyone please explain the difference between plexus-classworlds and (plain) classworlds?
These two are confusing and can't see the difference. Plexus classworlds contains almost no description. Apparently, a maven-based Java project uses both, I don't understand why.
Is it possible to replace classworlds with plexus-classworlds without much hassle?
I'm gonna answer that, even though the question is so old...
classworlds was migrated to plexus-classworlds, but the documentation on the site doesn't seem to keep up with that... the best docs I've seen was on classworlds 1.1-SNAPSHOT, although the current is plexus-classworlds 2.4.1-SNAPSHOT, and there is hardly any doc there.
if you look at plexus-classworlds, you can also see the original org.codehaus.classworlds package, with class comments like this:
A compatibility wrapper for org.codehaus.plexus.classworlds.launcher.Launcher provided for legacy code
which means that they thought about migration, but of course nothing replaces a thorough test.