We Keep Coding

Using Nuxt context inside custom js class

I'm new in Nuxt, Vue and JS at all. So I can't understand how exactly imports and exports works in JS, what is it about contexts and more..
So I have a class (~/helpers/foo.js)
export default class Foo {
static bar () {
console.log(this.$nuxt); // or this.$config, this.$nuxt.$config or smth
}
}
and in some component I called this function and got (it correctly imported and working) and got "undefined" in console on this console.log
Can someone explain me, how this is working? How can I pass the Nuxt's context to my class (if I can)? Should I define my class as a plugin for Nuxt (and rewrite it to single function 'cos Nuxt's plugins should be a fn? Class in my case used as a namespace for some functions, that is used for ab-testing)

First off, if you're new to JS, you should not be using Vue. Even less Nuxt, learn the basics and come back. You'll get a far easier time debugging and learning overall.
Skipping steps will not good in the mid/long term.
As for your question, you don't need to use Classes overall, especially for what you showed.
You can use the following answer to have both a successful export + import and the usage of Vue/Nuxt's context in a .js file. Reading the export page from MDN can also help quite a lot.

How to fix circular dependency between functions in javascript [duplicate]

Trying to find a good and proper pattern to handle a circular module dependency in Python. Usually, the solution is to remove it (through refactoring); however, in this particular case we would really like to have the functionality that requires the circular import.
EDIT: According to answers below, the usual angle of attack for this kind of issue would be a refactor. However, for the sake of this question, assume that is not an option (for whatever reason).
The problem:
The logging module requires the configuration module for some of its configuration data. However, for some of the configuration functions I would really like to use the custom logging functions that are defined in the logging module. Obviously, importing the logging module in configuration raises an error.
The possible solutions we can think of:
Don't do it. As I said before, this is not a good option, unless all other possibilities are ugly and bad.
Monkey-patch the module. This doesn't sound too bad: load the logging module dynamically into configuration after the initial import, and before any of its functions are actually used. This implies defining global, per-module variables, though.
Dependency injection. I've read and run into dependency injection alternatives (particularly in the Java Enterprise space) and they remove some of this headache; however, they may be too complicated to use and manage, which is something we'd like to avoid. I'm not aware of how the panorama is about this in Python, though.
What is a good way to enable this functionality?
Thanks very much!

As already said, there's probably some refactoring needed. According to the names, it might be ok if a logging modules uses configuration, when thinking about what things should be in configuration one think about configuration parameters, then a question arises, why is that configuration logging at all?
Chances are that the parts of the code under configuration that uses logging does not belong to the configuration module: seems like it is doing some kind of processing and logging either results or errors.
Without inner knowledge, and using only common sense, a "configuration" module should be something simple without much processing and it should be a leaf in the import tree.
Hope it helps!

Will this work for you?
# MODULE a (file a.py)
import b
HELLO = "Hello"
# MODULE b (file b.py)
try:
import a
# All the code for b goes here, for example:
print("b done",a.HELLO))
except:
if hasattr(a,'HELLO'):
raise
else:
pass
Now I can do an import b. When the circular import (caused by the import b statement in a) throws an exception, it gets caught and discarded. Of course your entire module b will have to indented one extra block spacing, and you have to have inside knowledge of where the variable HELLO is declared in a.
If you don't want to modify b.py by inserting the try:except: logic, you can move the whole b source to a new file, call it c.py, and make a simple file b.py like this:
# new Module b.py
try:
from c import *
print("b done",a.HELLO)
except:
if hasattr(a,"HELLO"):
raise
else:
pass
# The c.py file is now a copy of b.py:
import a
# All the code from the original b, for example:
print("b done",a.HELLO))
This will import the entire namespace from c to b, and paper over the circular import as well.
I realize this is gross, so don't tell anyone about it.

A cyclic module dependency is usually a code smell.
It indicates that part of the code should be re-factored so that it is external to both modules.

So if I'm reading your use case right, logging accesses configuration to get configuration data. However, configuration has some functions that, when called, require that stuff from logging be imported in configuration.
If that is the case (that is, configuration doesn't really need logging until you start calling functions), the answer is simple: in configuration, place all the imports from logging at the bottom of the file, after all the class, function and constant definitions.
Python reads things from top to bottom: when it comes across an import statement in configuration, it runs it, but at this point, configuration already exists as a module that can be imported, even if it's not fully initialized yet: it only has the attributes that were declared before the import statement was run.
I do agree with the others though, that circular imports are usually a code smell.

JS import is returning syntax error

This is a bit tricky, so I'll try to explain it well.
We use an erp solution where we can create ad hoc forms. On those forms, we can program some js and use an internal API provided by our solution developers.
Now we are facing the case that several different forms have to use common data structures and functionalities (for data validation, use interaction, etc...).
We can include all the code in each form and make it work, but it seems like a poor solution. It'd probable be a lot better if we generate a js library where we export those data structures and funcionalities, so we can import them in every form and just update it in one file.
The fact is that we are receiving a syntax error when we try to import a public library, probably because on execution time, the code we type is encased into a function into our developer's code.
ourProviderObject.ourProviderMethod('formName').clientLogic =
function(datpar, self, editable, store) {
import 'https://pathToOurTestLibrary.js'; //here starts our code!!!
So... I'm wondering why the syntax error. If some operation like this (importing a file from within a function) is not allowed I'd be expecting another type of error.
It's possible to make an import from within a function?
If it is... what could be the reason behind a syntax error?

Ok... I've switched from IE to FF and the error has turned much more clarifying:
SyntaxError: import declarations may only appear at top level of a module.
So I supose that answers my question, you cannot import a file from within a function or a callback

How to validate import functions?

I am writing a web app as a hobby using nodejs and react.
I have a file where I use some utilities functions, for example foo.
After using this function in some other files, I have decided to change the export and to wrap the function in an object, like Util.foo.
There was one file that I forgot to change the import statement to object instead of function, and I was calling foo() instead of Util.foo().
I couldn't catch it in my webpack build and not even in my unit tests, I cought it only when running the code and executing the appropriate function.
My question is, how can I avoid future mistakes like this? Are there any tools other than refactoring tools for this matter?
By the way, I am using Atom IDE.

This should have been caught by your unit tests if this part of your code is covered completely.
Calling a non-existing function will result in an error along the lines of undefined is not a function and should fail your test case.
To avoid issues like this, make sure your test coverage is exhausting. A test coverage tool like Istanbul may by helpful in determining areas for improvement.

Typescript and sql.js - how to tell Typescript it's there

I might be approaching this completely incorrectly, so any advice is appreciated. I'm currently trying to dig in deep to Typescript, and have decided to simultaneously use Sql.js (the JS version of SQLite) at the same time...
My first instinct to use Sql.js was to search for a .d.ts set of bindings around Sql.js so that I could easily start using it with TS. I've come up with no bindings so far (I don't think one exists yet), but figured I could just start "define"-ing in the stuff that I need from the library...
Starting with one of the simple examples from the "sql.js" docs, you have something like this:
var sql = window.SQL;
var db = new sql.Database();
Moving to the typescript side, I wanted to let TS know that after the sql.js library is included, the window object now has a property called SQL, which is essentially the hook to the rest of the library. I figured I needed to do this because, of course, when I type "window." (window-dot) in Visual Studio in my TS file, the Intellisense presented doesn't know about the SQL property now hanging off of "window". So... I dug around Stack, and concluded that I could solve this with a "declare" which I basically see as a way to tell TS just enough about the libraries that I don't have binding files for (.d.ts files).
However, in doing this, I can't seem to construct the syntax for such a declaration. I've tried:
declare var window.SQL : any;
declare var window.SQL;
declare var SQL = window.SQL;
declare window.SQL;
None of these work, of course.
So, the question is, how can I let TS know about new properties introduced by JS libraries on standard objects like "window", and the follow up question is, of course, is this even the right way to be approaching this?
Thanks for any insight.

Now that we have type definitions for SQL.js, and as of Typescript 2.0, the ability to install them easily, you can just do this:
npm install #types/sql.js
Then, that typings file will automatically be picked up by the compiler, and it will know that there is a SQL object. Here is the full definition:
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/sql.js/sql.js.d.ts

window is declared to be of type interface Window (in lib.d.ts). So you need to add to that if you want to use window.SQL :
interface Window{
SQL:any;
}
var sql = window.SQL;
var db = new sql.Database();
Recommend:
Personally I would recommend not using it off of window and just do
declare var SQL:any;
var db = new SQL.Database();
By default the variable access in the browser is on window.

OK, I think I've figured it out, although I'm still not sure if this is the preferred method.
In inspecting lib.d.ts, which is pretty much the heart of the sun as far as declarations go, I found the declaration of the interface for Window more than once. That led me to the conclusion that TS interface declarations (and likely other declarations) can essentially be "partials". It appears that the definition of any interface can be extended by simply adding extra items in a brand new declaration...
So, currently, my angry red squiggly line under "window.SQL" has gone away by simply adding the following:
interface Window {
SQL: any;
}
This seems to work because in lib.d.ts, the "window" variable is defined as a "Window" like this:
declare var window: Window;
... on line 9867 of the file in case others are looking for it. So, the net effect seems to be, I extended the definition of "Window" based on knowing that sql.js would make a new property called "SQL" on it.
HTH, in case anyone else is spelunking the same concepts.