I'm getting this error when try to create a map:
I'm currently using version "datamaps": "^0.5.8", this is directly from my package.json. I also checked the package.json in the actual package to see where main was pointing:
I found a related issue, maybe even the same issue here:
https://github.com/markmarkoh/datamaps/issues/259
Problem is that no one ever said what the answer was, one person mentioned that only a specific country js file was being loaded but I checked and datamaps.all.js is being loaded.
This is to be attributed to the new modularity of D3 v4, which made it necessary to flatten namespaces:
However, there is one unavoidable consequence of adopting ES6 modules: every symbol in D3 4.0 now shares a flat namespace rather than the nested one of D3 3.x.
For your code this means that some references using the d3-geo module are invalid because they refer to properties which are no longer available in v4:
Geographies (d3-geo)
d3.geo.albersUsa ↦ d3.geoAlbersUsa
Because datamaps has defined a dependency on D3 like ^3.5.6 this will include D3 v4. However, because of the above mentioned changes in the namespace you will have to use a D3 v3 instead.
Related
On my site (written in React) I use a calendar so that the user can select a date and time range. For this I use the react-advanced-datetimerange-picker library.
Also in index.js file I use <React.StrictMode>. Because of this, when working with the library, I have some warnings. I would like to get rid of them.
I know the easiest way to remove <React.StrictMode>.
But this is not entirely true.
Below is a part of my code
return (
<DateTimeRangeContainer
ranges={ranges}
autoApply={true}
start={time.start}
end={time.end}
local={local}
applyCallback={handleDateRangeChange}
forceMobileMode
years={[2022, 2025]}
style={styleRange}
>
</DateTimeRangeContainer>
);
The whole problem lies in the DateTimeRangeContainer component. If I remove it, the warnings disappear. So here are the warnings I have:
react-dom.development.js:86 Warning: Legacy context API has been detected within a strict-mode tree. The old API will be supported in all 16.x releases, but applications using it should migrate to the new version. Please update the following components: FormControl. Learn more about this warning here: https://reactjs.org/link/legacy-context
and second..
react-dom.development.js:86 Warning: findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of DateTimeRangeContainer which is inside StrictMode. Instead, add a ref directly to the element you want to reference. Learn more about using refs safely here: https://reactjs.org/link/strict-mode-find-node
Help me fix them
The issue is most likely because of an older version of react used in the library. One workaround is to use another library or another one is to wait for the author to update the library.
I created an issue on the library repo. Please find it here
In Webpack 5, module.reasons was removed (see: https://webpack.js.org/blog/2020-10-10-webpack-5-release/). From what I have been able to find, the documentation doesn't list an alternative. Documentation for the module graph is also pretty scarce.
We have build code that currently checks module.reasons inside of the splitChunksPlugin test() function. That code breaks in Webpack 5.
Does anyone know what the replacement for module.reasons is? I've tried looking stuff up in the module graph but I don't think the current module has been added yet because it is always undefined when calling getModule() on the graph.
do any of you face this problem , where vscode always take you to the type definition of a function and not the implementation.
For example,
I right click on the react setState function as below,
And VS code shows me the typescript file.
If its problem a, how do i fix it.
If not then how do I look at the implementation and not the type definition of a function.
This is a limitation of VS Code's intellisense. We don't attempt to parse js from inside node_modules for IntelliSense, so we have no way of mapping back to the original source code. Instead we rely on *.d.ts to provide definitions.
These two issues are tracking possible improvements to this:
https://github.com/Microsoft/TypeScript/issues/6209
https://github.com/Microsoft/TypeScript/issues/16792
In vscode v1.67 there is update with new Go to Source Definition command
Jump directly to a JavaScript implementation of a library function
using the new Go to Source Definition command. You can learn more
about this feature and share feedback in TypeScript issue #49003.
When using intellisense in VS-Code, it gives autocomplete suggestions for an older version of expect than what I'm using,. The API has changed since it was donated to the Jest project, but for some reason, it still shows the old methods, but none of the replacement methods, like toHaveProperty.
Took a lot of effort to find out why my tests weren't working, but haven't been able to find an answer as to what could be the cause.
VS Code sources its type definitions for JavaScript from the #types namespace on NPM, which contains definition files that are automatically pulled from the DefinitelyTyped GitHub repository.
In your case, the type definitions will be coming from the #types/expect package, which specifies in the README that it exposes the files from https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/expect.
If you look at the timestamps on said files, you'll notice they haven't been updated in 5 months! That is most likely the source of your issue.
You (or someone else) will need to submit an updated type definition to make automatic type acquisition function properly for that library. Alternatively, you can override the type definitions locally or disable the feature altogether.
I'm facing the problem of integrating requirejs with d3 and nvd3, and i found an easy solution using require's shim. Using the shim i can export a variable, and i can also define dependencies:
d3: { exports: 'd3' },
nvd3: {
exports: 'nv',
deps: ['d3']
},
In this way, i simply install d3 and other packages with bower, and include them with require, and it is really quick and clean.
Nonetheless, i faced the following problem: there are probably some clashes between the global d3 variable and the local one (the one injected in the requiring modules). It is a d3 / require / nvd3 integration problem related to transitions and selections. I don't fully understand the problem, but i can already make some considerations.
jquery has the same problem with require, and they provide the noconflict method to fix it
many libraries have this behavior, they export a global symbol, but as far as i know there is no ready fix from requirejs for the general problem
the problem is fixed if i rename all global references to d3 into d3 source to another name. I still have d3 in the injected module, but it is not conflicting anymore
As far as i can see, all d3 functionalities work this way, but one of the nvd3 charts has transitions broken probably because a selection or dispatcher is overwritten. It requires deep understanding of d3 internals to spot precisely the error, but probably a simple yet correct handling of the global symbol will clear the whole tally of similar problems.
Probably, due to the way requirejs handles shim dependencies, the global d3 symbol is exposed to nvd3. The same symbol, anyway, is not available to requiring modules, and will be overwritten somehow if injected (included in the module dependencies).
I tried also to wrap d3 in a module and properly return a local d3 variable, but looks like the problem still persists.
I also asked help about this on this d3 group discussion which hosts some previous posts about d3 and modules.
I added a test case here: https://github.com/danse/requirenvd3
The problem doesn't appear to be your RequireJS configuration but rather the fact that you're using d3.v3 and not d3.v2. I downgraded d3 in your test case, and the transitions worked fine. (The popups are still all off to the side, which I don't think they should be, but that doesn't seem to be what you are presently concerned about.) It's my understanding that nvd3 has a few problems with d3.v3, this probably being one. Also, note the version of d3 in ddotsenko's jsFiddle. That could explain why his solution didn't work when you implemented it using your own d3.v3 library.
First, you can bypass shim You don't need it to return anything for plain-JS. Just use globals.
Loading Angular from CDN via RequireJS is not injected
Second, while shim is semi-useful for declaring dependencies for scripts, you can do them explicitly as well:
require(['path/to/d3.min'], function(){
// nesting to insure d3 loads before nvd3
require(
[
'path/to/mylogic' // <- AMD module
,'path/to/nvd3.min' // <- actually a plain JS file
]
, function(mylogic /*, we ignore what nvd3 returns */){
window.nv // is available for you
}
)
})
Look at what I do in this main.js file (using "depend" requirejs plugin) and then in other files that require something that should be exported to a global variable I do:
define(['d3'], function (d3) {
// Code here ...
});
The depend plugin is really nice and allows you to setup hierarchical loading via depend!plugin[dependancy1, dependancy2] ("plugin" loads after "dependancy1" and "dependancy2" have loaded.