@sunesimonsen I remember a couple of people on twitter talking about being able to write js with jsdoc, and having typescript types extracted from that. The problem is that jsdoc is pretty limited when it comes to generics, if you might want to use those. And when I tried this approach in the very early days of that tooling, the output wasn't super useful
You don't want to write
.d.ts files by hand?
It is pretty limited amount of typing I want to expose.
It has a drop-in replacement called
blocked-at that uses async_hooks to also provide a stack trace of where the blocking operation was initiated. Unfortunately it has a big perf overhead, so it’s not suitable for production.
@gustavnikolaj :point_up:
Scripting with https://github.com/sunesimonsen/transformation is pretty fun and useful.
I am debugging a memory leak in a node.js application. I observe that my
rss is way bigger than my heapTotal and external memory segments combined when I inspect process.memoryUsage(). I would expect that heapTotal + external gives me all the memory used by js objects and c++ objects referenced from js. Am I missing something? Wouldn't a runaway rss number be an indication that theres some native code leaking? I am observing up to 70 to 80 percent of memory use being outside of heap and external...
Thanks for the suggestions on the event loop blocking @papandreou. I managed to convince the teams that they actually had a block without having to resort to scientific proofs :) Unfortunately we were sick all week so I never got back to you :(
@gustavnikolaj,
... so it's not an exact science. V8 doesn't automatically know that
external will only include memory that is allocated outside the JS heap and correctly reported using Isolate::AdjustAmountOfExternalAllocatedMemory: https://v8docs.nodesource.com/node-4.8/d5/dda/classv8_1_1_isolate.html#ae1a59cac60409d3922582c4af675473e... so it's not an exact science. V8 doesn't automatically know that
malloc gets called.
Maybe that explains the gap, depending on which native modules are involved?
These are the modules using nan as a dependency - that's the quickest way I know to check for native modules :) iconv, sharp, genx and node-expat.
I'd by default suspect that latter two most, but it actually seems to happen regardless of wether I engage the XML-related bit of the server :D
But I'll take a look at sharp :) Thanks for the pointer!
I made a Babel plugin for stylewars to minify CSS in place. Now my Hackernews example with 7 dependencies (VDOM, store, router and styling) is down to 12.7K JavaScript :tada:
That build tooling can be anything as I'm just following the rules of the web :-)
So if there was a snazzy asset-graph builder that would do it all, I would welcome it ;-)
I don't want to configure anything if I can avoid it.
Hello.
I am finding myself to often encounter such construct in React components:
useEffect(() => {
loadCapabilitiesAction().then(capabilityList => {
if (capabilityList) {
setCapabilities(capabilityList);
}
});
});It's all about fetching some data and setting the state which then renders some DOM.
It's not very straightforward to test it though.
Do you have any advice or direction to follow with unexpected?
A component test looks like that
const loadCapabilitiesActionPromise = Promise.resolve([
{ id: "mailadmin", metadata: {} },
{ id: "website_builder_premium", metadata: {} },
{ id: "wordpress", metadata: {} },
{ id: "webshop", metadata: {} },
{ id: "onephoto", metadata: {} },
{ id: "filemanager", metadata: {} },
{ id: "dns", metadata: {} },
{ id: "external_ssh", metadata: {} },
{ id: "backup", metadata: {} },
{ id: "php_mysql", metadata: {} },
{ id: "guest_users", metadata: {} }
]);
props.loadCapabilitiesAction.returns(loadCapabilitiesActionPromise);
let component = null;
await act(async () => {
component = mount(<QuickAccess {...props} />);
});
loadCapabilitiesActionPromise.then(() => {
expect(component, "not to contain test id", "quick-access-website-stats");
});but to be honest I am in an infinite loop with such an approach.
:disappointed:
You're mixing data fetching with your view in the same component, so you'll have to stub one to test the other.
One way to fix it is to split the component in two: One component that has all the view logic and take all the data as props, and then component with no "DOM-like" components, but the data fetching and a forward to the plain view component. Both components can be exported from the same file.
You can also isolate your data fetching logic in a similar function, so that you can test that in isolation without also bringing in React
Well this seems kind of important. https://twitter.com/bcrypt/status/1461591131930517504?t=8Osx7J5l7MZ79aoHIWNkKA&s=19
@papandreou I am considering "parking" https://www.npmjs.com/package/fetchception / https://github.com/gustavnikolaj/fetchception for a while - at least disabling dependency PRs and closing open ones. The module is only sparsely used (<100 weekly downloads), and it's just adding a lot of churn. Right now I need to do an update pass on linting dependencies in the project, but I'd rather just "park" the project until I see some indication that someone is actually using it :)
What are your thoughts? I have a couple of modules in a similar state, and I am considering applying that same solution, to stop the meaningless churn.
https://www.npmjs.com/package/httpception seems to be in much the same state. There's a constant churn of updates in the devDependencies to keep up with those, but the last actual released version is a year old :)