Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 27 07:08
    papandreou synchronize #845
  • Apr 27 07:08

    papandreou on update

    Add workaround to get the test … (compare)

  • Apr 26 21:37
    papandreou synchronize #784
  • Apr 26 21:37

    papandreou on camelCase

    Sketch out some basic tests Slow, naive implementation of t… Support camel case syntax withi… and 6 more (compare)

  • Apr 26 21:21

    papandreou on v13.0.0

    (compare)

  • Apr 26 21:21

    papandreou on master

    Add release notes 13.0.0 (compare)

  • Apr 26 21:10

    papandreou on update

    (compare)

  • Apr 26 21:10

    papandreou on master

    Update eslint-plugin-markdown t… Adjust configuration based on h… Merge pull request #820 from un… (compare)

  • Apr 26 21:10
    papandreou closed #820
  • Apr 26 21:03
    papandreou synchronize #820
  • Apr 26 21:03

    papandreou on update

    Adjust configuration based on h… (compare)

  • Apr 26 20:44
    papandreou synchronize #845
  • Apr 26 20:44

    papandreou on update

    Get most of the external tests … (compare)

  • Apr 26 19:43
    depfu[bot] synchronize #845
  • Apr 26 19:43

    depfu[bot] on update

    Update jest to version 27.4.5 (compare)

  • Apr 26 19:43
    papandreou commented #845
  • Apr 26 19:41

    papandreou on master

    Apply the jasmine patch for 4.x… (compare)

  • Apr 26 19:10

    papandreou on master

    Expect jasmine to exit with 3 w… (compare)

  • Apr 26 19:04

    papandreou on update

    (compare)

  • Apr 26 19:04
    papandreou closed #849
Andreas Lind
@papandreou
@gustavnikolaj, 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?
Gustav Nikolaj
@gustavnikolaj
That could certainly be an explanation
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
Andreas Lind
@papandreou
sharp, for sure :)
Gustav Nikolaj
@gustavnikolaj
We saw some very unfortunate interactions with sharp and ubuntu 18.04. We went from stable memory use to rampant leaks, pretty much making the apps unusable due to oomkilling... But they seemed mostly solved by enabling jemalloc.
But I'll take a look at sharp :) Thanks for the pointer!
Andreas Lind
@papandreou
At least the symptoms you list are consistent with what I've seen with sharp before.
Sune Simonsen
@sunesimonsen
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:
Andreas Lind
@papandreou
In bed with the enemy, huh? :)
Sune Simonsen
@sunesimonsen
Haha I only fighting for a no tooling developing experience, I think there will always be an optimizing build for production.
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 ;-)
Andreas Lind
@papandreou
I recently made a rollup integration :)
Sune Simonsen
@sunesimonsen
I know, ideally I want something that I can just point my HTML file and it just works. I made that for depository, but in general.
I don't want to configure anything if I can avoid it.
Andreas Lind
@papandreou
Same :)
Miroslav Nikolov
@moubi

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:
Gustav Nikolaj
@gustavnikolaj

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
Miroslav Nikolov
@moubi
Thanks Gustav. I am not sure which approach will win at the end.
I am also a bit hesitant about abstracting too much at the moment.
Peter Müller
@Munter
Andreas Lind
@papandreou
Argh, thanks for sharing :scream:
Gustav Nikolaj
@gustavnikolaj
Happy new year everyone! 🎉 And welcome back 🥳
Andreas Lind
@papandreou
Happy new year! :tada:
Sune Simonsen
@sunesimonsen
🍾🥂🙌
Peter Müller
@Munter
Happy new year!
Gustav Nikolaj
@gustavnikolaj
@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.
Andreas Lind
@papandreou
We have a project at work that uses it, but no objections from me.
Gustav Nikolaj
@gustavnikolaj
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 :)
Andreas Lind
@papandreou
New year's resolution kicking in? :)
Gustav Nikolaj
@gustavnikolaj
It's not that I'll sunset the project, it's just that I'd like to not get those PRs when there's no need for the change. :)
Andreas Lind
@papandreou
Yeah, I know, it's a pretty sad state where all the common dev deps are dropping old node versions all the time..
Gustav Nikolaj
@gustavnikolaj
Hehe... Well, more like spring new-years cleaning :)
Yeah, and the funny thing is that it seems to mostly be the "DX"-focused tools that keep on churning. :)
Peter Müller
@Munter
There's not much value in keeping dependencies always up to date for projects that don't get new releases. Especially dev dependencies
Andreas Lind
@papandreou
I have to agree with that.
Gustav Nikolaj
@gustavnikolaj
Totally
There's a couple of ones that I "share" with you @papandreou, which all seem to have fallen into the same thing: httpception, fetchception, express-compiless, express-extractheaders
I have no problem keeping them maintained, but I would prefer a solution where it is driven by actual requests for help rather than a robot keeping me occupied :D
Andreas Lind
@papandreou
I wonder if there's a middle ground between the churn and disabling depfu altogether.
Gustav Nikolaj
@gustavnikolaj
Yeah, what we need is an ignore devDependencies option for depfu :)
Andreas Lind
@papandreou
Or just leave the PRs open... But that also sends a bad message.
Gustav Nikolaj
@gustavnikolaj
It also rubs me the wrong way. I would prefer an option that means that I can still get notifications for issues / prs in the repos but not having to deal with these PRs :)
Andreas Lind
@papandreou
Maybe a tool that's more aware of the node.js/engine versions supported by the project itself and its dependencies.
Gustav Nikolaj
@gustavnikolaj
(we still also use {fetch,http}ception here at one.com, and I think most of the other ones - so it's not like I want to abandon them)