As found on the official documentation IE11 does not support FormData at all or at least not much enough I need to.
Inside my code I have to loop through the entries of an FormData element. For this task I use the entries() function which is not working on IE giving me the error
Object doesn't support property or method 'entries'
I already added https://github.com/jimmywarting/FormData via npm to my project and added it to my entry in webpack.config.js which then looked something like this.
const webpack = require("webpack");
const path = require("path");
module.exports = {
entry: {
app: ["babel-polyfill", "formdata-polyfill", "whatwg-fetch", "./Scripts/Modules/index.ts"]
},
}
In the console I can see that formdata.min.js is loaded. As the error still occurs it seems like it does not use the polyfill as it should. It still uses the default one which fails.
How can I tell my TypeScript code to use the polyfill-version instead of the browser's default implementation as the package does not provied any d.ts files?
Is this even possible? If not - what are possible workarounds for such a scenario?
This is what the FormData object is looking like in the dev-tools:
which only has append as method defined
Not sure if it may helps you but I got this issue today and it seems that the version of the polyfill provided via NPM does not completely override the FormData object, so is not suitable to IE11 or Edge.
I found switching to the V3 of the library fixed that. In order to do that I got the content of the FormData.js file from the github repository and added it as a component in my own custom JavaScript code.
I use WebPack to, got some other issues with IE11, still investigating.
Let me know how it goes by including the content directly instead of getting it from NPM.
Related
I'm using config-overrides.js with string-replace-loader in order to change the content of a file before being compiled by webpack.
But because of the caching system of webpack (cache option) the loader is not being executed, if I set cache = false everything works just fine (exactly like the production build).
I've spent several hours trying to understand how to exclude a file from caching, but whatever I've found does not work as expected and I'm kinda out of ideas.
Is there any way to achieve this without completely disabling the caching system?
[EDIT]
I know the question asks about files, but my problem was related to the index.js file which imports a component conditionally based on a specific value inside an external config file.
After some more couple of hours of investigating I've found what I was looking for.
Here is the official documentation regarding this exactly use case.
Basically what we can do to invalidate the cache is to use the cache object as below:
cache = {
type: 'filesystem',
version: `${any external variable/value which may change in the future}`, // Keep the `${}`
};
cache.version is a string. Passing a different string will invalidate the persistent cache.
I'm using it like this and it's working great so far.
const invalidateCacheValues = [
config.my_value_0,
config.my_value_1
];
webpackConfig['cache'] = {
type: 'filesystem',
version: `${invalidateCacheValues.join('|')}`,
};
I'm quite new to javascript and jsfiddle. I've been able to toy around with other fiddles that I find, but setting one up myself has proved difficult.
I'm attempting to use a library from npm to get a proof of concept for how it might work. I'm not sure why my import of the module is not working with jsfiddle.
What am I missing to get my fiddle working?
used the resourced bar to import the unpkg script
https://unpkg.com/browse/json-query#2.2.2/index.js
tried using the method outlined in the package readme
var json = [...]
jsonQuery('[DisplayText]', json)
When I follow the unpkg link I see that it has requires such as:
var State = require('./lib/state')
The problem is not only can the browser not understand require, it doesn't have files like ./lib/state available.
I think the problem here is that you are trying to download the raw source, which needs to be built with something like webpack before it can be used in the browser.
I'm using jest to test a custom module that implements react embla carousel.
I received an error related to jsdom lacking an implementation for window.getComputedStyle(elt, pseudoElt)
Error: Not implemented: window.computedStyle(elt, pseudoElt)
After a bit of searching I found out that the second parameter wasn't supported by jsdom and the wonderful folks at #testing-library had an option to do... something... about it.
Reference
https://testing-library.com/docs/dom-testing-library/api-configuration#computedstylesupportspseudoelements
jest-setup.js:
import { configure } from '#testing-library/dom';
configure({
computedStyleSupportsPseudoElements: true
})
import '#testing-library/jest-dom';
Unfortunately though, this doesn't seem to fix my error. I know the configuration is being applied because I set some other configuration options that broke all my tests.
Am I not applying something correctly or is there potentially another workaround? I don't need the full functionality of the carousel in the test I just want to make sure the data I pass to the view is being rendered properly.
I got the same error when updating Jest to the latest version (26.6.3). Calling getComputedStyle as a window property in the embla-carousel code was causing this issue for me:
const pseudoString = window.getComputedStyle(node, ':before').content
I also tried to solve this using the #testing-library/dom to no avail. But when I removed window and called getComputedStyle directly the issue went away:
const pseudoString = getComputedStyle(node, ':before').content
I've released embla-carousel v4.4.1 which includes a fix for this issue. Please install this version and the issue should go away.
I am utterly confused as how to insert individual foundation javascript. it always seem to break my code. for example I need to use the dropdown menu js. in the documentation it state
Initializing
The file foundation.dropdownMenu.js must be included in your JavaScript to use this plugin,
along with foundation.core.js.
This plugin also requires these utility libraries:
foundation.util.keyboard.js
foundation.util.box.js
foundation.util.nest.js
this seem simple enough so I did the following in this order
bower_components/foundation-sites/js/foundation.core.js //check
bower_components/foundation-sites/js/foundation.util.mediaQuery.js
bower_components/foundation-sites/js/foundation.util.timerAndImageLoader.js
bower_components/foundation-sites/js/foundation.util.keyboard.js //check
bower_components/foundation-sites/js/foundation.util.box.js //check
bower_components/foundation-sites/js/foundation.util.nest.js //check
bower_components/foundation-sites/js/foundation.dropdown.js
bower_components/foundation-sites/js/foundation.dropdownMenu.js //check
bower_components/foundation-sites/js/foundation.equalizer.js
I follow what logical for me core 1st than util than plugin
yet it told me foundation.util.nest.js:6 Uncaught SyntaxError: Unexpected token =
if I put all foundation.min.js file the error go away, so I know it must be a dependency is missing or the order is not correct
is there any resource out there that is clear on the dependency of foundation js? instead everytime I have to trail and error it.
I'm having the same issue on my end. I am using Foundation as a GIT subtree in my project and actually have used this on a site I made just last week.
It seems that the problem is a newer version of function parameter declarations. In the code I had working, v6.1.2, the code in foundation.util.nest.js is:
Foundation.Nest = {
Feather: function(menu, type){
menu.attr('role', 'menubar');
type = type || 'zf';
versus the code in the newest version 6.2.0 which is:
const Nest = {
Feather(menu, type = 'zf') {
menu.attr('role', 'menubar');
It's that default/fallback declaration of "type" that seems to ruin everything. I look forward to a fix myself.
According to this link, my current version of Chrome (48) doesn't yet support default function parameters.
As of Foundation v6.2.0 the JavaScript codebase has been updated to ES6.
https://github.com/zurb/foundation-sites/releases
You'll need to add Babel to your build process to compile the ES6 code.
They have supplied a tutorial for this here:
https://github.com/zurb/foundation-sites/wiki/Upgrading-to-Foundation-6.2
Hope this helps.
Is there a way I can add a new package to dojo config? I know I can do this: Add packages when dojo.js loads.
<script src='dojo_1.7.2/dojo/dojo.js'
data-dojo-config="async:true,isDebug:true,parseOnLoad:false,
packages:[{name:'project1',location:'../../js/proj1'},
{name:'common',location:'../../common'}]"></script>
I want to be able to add new packages at runtime.
dojo.registerModulePath did do this job prior to dojo1.6 (i think) but its now deprecated in 1.7
I am using dojo 1.7.2.
Thanks.
You can add extra packages after load by calling require with a config object.
Eg:
require({
packages: [
{"name": "myLib", "location": "release/myLib"}
]
});
This will however, create another instance of Dojo, according to the documentation (dojo/_base/config). Also, this is version 1.8 code; I don't think it works with 1.7.
I thought it might possible to push an extra object to dojoConfig or require.rawConfig but these are not picked-up by the loader. It appears that config cannot be changed after load.
You can pass a config object to require, so:
Eg.
dojoConfig.packages.push({"name": "myLib", "location": "release/myLib"});
require(dojoConfig, [...moduleIds...], function(...arguments...) {
});
This will work for the individual require but will not modify the global config (and hence will not work in define() or subsequent calls to require()). Again, I'm using 1.8 here but I assume it works in 1.7.
There may be another simpler way of making this work that someone else as found?
The solution by Stephen Simpson didn't seem to work right for me with dojo v1.13. It ignored the given location and was still trying to load the files relative to the default basePath despite of the project path starting it with a /. I got errors in the console, too.
But the documentation also mentions the paths parameter which worked for me. In your case:
require({paths:{"project1": "../../js/proj1", …}});
It probably worked for you because you're using a relative path and I don't.
It used to be dojo.registerModulePath("myModule", "/path/goes/here");.