I'm trying to test a component that imports a .gql file. When I try to build the component in a Jest file, I receive this error:
( object. anonymous function(module exports require __dirname __filename global jest) {
query getUser {
ˆˆˆˆˆˆˆ
<script>
import GET_USER from 'PATH';
ˆ
Does anyone have any idea of how to ignore the import? Because I don't need to test the GraphQL call.
GraphQL documents (which typically have a .gql extension) can be imported directly if you use webpack and utilize the loader that comes with graphql-tag. Jest does not work with webpack out of the box and needs to be configured to handle any imports of asset files like stylesheets, images, etc. This process is outlined in the docs.
According to the graphql-tag documentation:
Testing environments that don't support Webpack require additional configuration. For Jest use jest-transform-graphql.
So you can utilize jest-transform-graphql along with the babel-jest plugin, which you're probably already using:
"jest": {
"transform": {
"\\.(gql|graphql)$": "jest-transform-graphql",
".*": "babel-jest"
}
}
Mocking the file is technically possible by adding the moduleNameMapper config option as shown in the docs, however, doing so is likely to break your components.
Related
I'd like to render GraphQL Playground as a React component in one of my pages but it fails due to missing file-loader in webpack. Is there a way to fix this in docs or do I need to create new plugin with new webpack config?
Is it good idea to integrate Playground and Docusaurus at all?
Thanks for your ideas...
A few Docusaurus sites have embedded playgrounds:
Hermes
Uniforms
In your case you will have to write a plugin to extend the webpack config with file-loader.
Not sure if you found a better way but check out: https://www.npmjs.com/package/graphql-playground-react
You can embed this react component directly in your react app - It looks like Apollo also uses the vanilla JS version of this
I just had exactly the same problem. Basically, Docusaurus with a gQL Playground Integration runs fine in local but won't compile due to errors when running yarn build as above.
In the end I found the answer is in Docusaurus, not in building a custom compiler:
I switched from using graphql-react-playground to GraphiQL: package: "graphiql": "^1.8.7"
This moved my error on to a weird one with no references anywhere on the web (rare for me): "no valid fetcher implementation available"
I fixed the above by importing createGraphiQLFetcher from '#graphiql/create-fetcher' to my component
Then the error was around not being able to find a window component, this was an easy one, I followed docusaurus docs here: https://docusaurus.io/docs/docusaurus-core#browseronly and wrapped my component on this page in like this:
import BrowserOnly from '#docusaurus/BrowserOnly';
const Explorer = () => {
const { siteConfig } = useDocusaurusContext();
return (
<BrowserOnly fallback={Loading...}>
{() => {
const GraphEx = GraphExplorer
return
}}
);
}
This now works and builds successfully
Nativescript Angular is well known for its code sharing properties. I am trying to simplify my design by using only 1 typescript file instead of splitting into the .ts and the .tns.ts file.
I was trying to import { Page } from "tns-core-modules/ui/page"; in the .ts. When running on Android, the code works flawlessly, but if I ng serve for the web app, it says Module not found: Error: Can't resolve 'tns-core-modules/ui/page'.
The reason why I wanted to import the page module is because of setting the action bar properties
constructor(private page: Page) {
if (isAndroid) {
console.log("This is Android");
this.page.actionBarHidden = true;
}
}
I was hoping to import the tns-core-modules/ui/page and some other tns-core-modules in the same file as the angular web app. Is it possible to do so? Or is it a must to split into the .ts and the .tns.ts files?
You have to go with platform specific ts files, one for web and one for tns, Page won't be valid while running inside a browser (ng serve).
If you prefer to reuse most of your code, try writting a common / base ts component, extend platform specific ts files from the common / base ts component, inject Page only within the tns specific ts file.
To set the context I am creating a CRUD application for Laravel. It is installed via composer and the sources are therefore in the vendor/organization/package directory.
In my project, I use Datatable. So I use Laravel Mix to compile my sources and a command line allows to copy JS and CSS compiled files into the public directory of the Laravel Host application.
I would like however that the developers who will use my library can customize the display of some Datatable cells. To do this you must use Datatable's createdCell configuration.
$('#example').dataTable( {
"columnDefs": [ {
"targets": 3,
"createdCell": function (td, cellData, rowData, row, col) {
if ( cellData < 1 ) {
$(td).css('color', 'red')
}
}
} ]
});
The problem is that the JS sources of my project are already compiled...
For the moment I found a temporary solution that consists in leaving the JS sources in vendor/organization/package but copying the webpack.mix.js configuration into the Host application and asking the developers to compile themselves. The problem is that all JS dependencies must also be installed and it doesn't take very seriously to force the developers to compile sources before being able to use my library.
What are good practices to achieve this objective?
The following source may help, but I confess I don't know how to apply it to Laravel:
How to bundle vendor scripts separately and require them as needed with Webpack?
Thank you for your help.
Sorry for the obfuscated question, I'll elaborate my problem. I am currently developing a single page app in Aurelia, and I found a lib I want to try out: https://github.com/hootsuite/grid. I did the normal jspm routine:
jspm install github:hootsuite/grid
which installs successfully and adds the following to the systemjs config:
map: {
"hootsuite/grid": "github:hootsuite/grid#1.0.0",
The package file looks like this:
define(["github:hootsuite/grid#1.0.0/src/gridList.js"], function(main) {
return main;
});
Which enables me import the module as expected:
import * as grid from 'hootsuite/grid';
So far so good, but the js file referenced by the module is not the one I am interested in (src/gridList.js), the src folder also contains a jquery plugin named "jquery.gridlist.js" which is the file I actually want to resolve. I managed to "fix/hack" it by adding an additional AMD module definition in the module file (grid#1.0.0.js):
define('gridlist', ["github:hootsuite/grid#1.0.0/src/gridList.js"], function(main) {
return main;
});
define(["github:hootsuite/grid#1.0.0/src/jquery.gridList.js", "github:hootsuite/grid#1.0.0/src/gridList.js"], function(main) {
return main;
});
This is not a viable solution because the jspm_modules are not a part of source-control, thus it will have to be patched manually for every dev. So, whats the best approach for this type of problem? Or which features am I missing out on which removes the problem entirely?
Is there a way to include regular javascript files in the Firefox SDK background script?
If I just have a script file that defines some variables, include it and access those in the background script.
Its my understanding so far that they MUST be CommonJS modules. I am porting a Chrome Ext that also uses alot of common code with a mobile app, etc which I'd rather not try converting to CommonJS modules.
Is this possible?
Its my understanding so far that they MUST be CommonJS modules.
That's correct.
If you want to include standard JS files that are already structured in some way, you'd either have to inject them into a page worker, which will
Create a permanent, invisible page and access its DOM,
then send in and out the few variables needed and resulting, respectively, using port, as I explained in your last question.
Or you could use some sort of file concatenation (if you minify your files, this should already happen), then save this new JS file in the lib folder, and require/export those same variables.
These approaches only require you to input/output the variables that are needed externally from the system of files you already have in place, so it's less of a pain than converting each file to commonJS.
NB: I use Angular for my webapp, and have used some modules for both like so
var syncHelper = function() {
this.filter = function(objects, prop) {
// do stuff
}
this.consolidate = function(local, server, id) {
//more stuff
}
}
// app is my angular webapp var
if (typeof app==='undefined') syncHelper.call(exports);
else app.service('syncHelper', syncHelper);