4 ms·

It doesn't seem that bad actually. I prefer a developer to add an existing well-proven package than copy and paste some lines from the internet, since many time

It doesn't seem that bad actually. I prefer a developer to add an existing well-proven package than copy and paste some lines from the internet, since many times these lines won't handle many corner cases. That's the strength of packages - they already handle the case of empty array, empty string, invalid data, utf-8, that glitch in Chrome and plenty of other "little" things that break Stackoverflow code snippets.

baby 9y ago
so you end up with 100 dependencies? 35 LOC is NOT worth a package.
- laurent123456 9y ago
  But it's 35 LOC because it's probably not handling various cases that aren't obvious at first. That particular package went through many versions and is widely used so there's a chance it's robust and will be maintained over time. That's one less maintenance task to do.
  - seba_dos1 9y ago
    I have took a look at that particular package ([edit] not really, see below), and it seems to be a very short code, grown into more lines by providing API for configuration (delay, smooth or not, duration, offset etc.) and various convenience wrappers for easy mixing-in into your components. It also implements scroll-spy behavior. Versions (and open issues) are mostly about adding/changing/fixing yet another of those convenience wrappers. If you do a lot of scrolling into various components on various actions on your page, this module can sure be handy. Otherwise, it doesn't really seem to do anything better than a simple snippet copy'n'pasted into proper place. Those "non obvious at first cases" in this case seem to be mostly about how developer uses it in their code, so if you just use it in one place to do one specific thing, there are none. [edit] Oh, sorry! I saw "react-scroll", while the article mentions "react-scroll-to-component". This one actually consists of 32 LOC and there's nothing more to it! It depends on "scroll-to", which is 66 LOC, but most of it is due to formatting and API and could be probably squeezed into a few lines without losing much clarity. Then it depends on a "tween", which actually does the smoothing and could be the one thing actually worth depending on, if that's what you need to achieve. In simplest cases it boils down into a one-liner as well, but it's a well-known library anyway. "scroll-to" also depends on "raf", which is a polyfill you might or might not need.
  - musage 9y ago
    https://github.com/flyingant/react-scroll-to-component/blob/master/index.js https://github.com/flyingant/react-scroll-to-component/blob/... What non-obvious cases does this handle? It hasn't been changed in a year, it the main function wasn't updated even once after the initial commit (so that evolution must have taken place elsewhere?). It also uses a string as a parameter, which most people will probably supply as string literal. Use it like that here and there and you're fine, use it a lot (or in a tight loop), and you're just creating unnecessary crap for the GC to deal with.
- hateduser2 9y ago
  Is having 100 dependencies bad?
  - baby 9y ago
    As someone who audit code for a living, yes it is bad oO that would be a nightmare to go through
- lmm 9y ago
  35 LOC is absolutely worth a package, unless your package manager is really bad; that means 34 fewer lines in your codebase.
  - mcguire 9y ago
    Well, yeah, 32 fewer in your codebase, 28 fewer in your build, 10 fewer that you have to type, 15 more you have to understand, 37 more you have to debug... Watch out for actively developed dependencies.
    - lmm 9y ago
      I'd say rather: approach a dependency upgrade like any other code change, and be prepared to refactor aggressively (including by copying code and removing the dependency, if necessary) as with any other code change.

baby 9y ago

so you end up with 100 dependencies? 35 LOC is NOT worth a package.

laurent123456 9y ago
But it's 35 LOC because it's probably not handling various cases that aren't obvious at first. That particular package went through many versions and is widely used so there's a chance it's robust and will be maintained over time. That's one less maintenance task to do.
- seba_dos1 9y ago
  I have took a look at that particular package ([edit] not really, see below), and it seems to be a very short code, grown into more lines by providing API for configuration (delay, smooth or not, duration, offset etc.) and various convenience wrappers for easy mixing-in into your components. It also implements scroll-spy behavior. Versions (and open issues) are mostly about adding/changing/fixing yet another of those convenience wrappers. If you do a lot of scrolling into various components on various actions on your page, this module can sure be handy. Otherwise, it doesn't really seem to do anything better than a simple snippet copy'n'pasted into proper place. Those "non obvious at first cases" in this case seem to be mostly about how developer uses it in their code, so if you just use it in one place to do one specific thing, there are none. [edit] Oh, sorry! I saw "react-scroll", while the article mentions "react-scroll-to-component". This one actually consists of 32 LOC and there's nothing more to it! It depends on "scroll-to", which is 66 LOC, but most of it is due to formatting and API and could be probably squeezed into a few lines without losing much clarity. Then it depends on a "tween", which actually does the smoothing and could be the one thing actually worth depending on, if that's what you need to achieve. In simplest cases it boils down into a one-liner as well, but it's a well-known library anyway. "scroll-to" also depends on "raf", which is a polyfill you might or might not need.
- musage 9y ago
  https://github.com/flyingant/react-scroll-to-component/blob/master/index.js https://github.com/flyingant/react-scroll-to-component/blob/... What non-obvious cases does this handle? It hasn't been changed in a year, it the main function wasn't updated even once after the initial commit (so that evolution must have taken place elsewhere?). It also uses a string as a parameter, which most people will probably supply as string literal. Use it like that here and there and you're fine, use it a lot (or in a tight loop), and you're just creating unnecessary crap for the GC to deal with.
hateduser2 9y ago
Is having 100 dependencies bad?
- baby 9y ago
  As someone who audit code for a living, yes it is bad oO that would be a nightmare to go through
lmm 9y ago
35 LOC is absolutely worth a package, unless your package manager is really bad; that means 34 fewer lines in your codebase.
- mcguire 9y ago
  Well, yeah, 32 fewer in your codebase, 28 fewer in your build, 10 fewer that you have to type, 15 more you have to understand, 37 more you have to debug... Watch out for actively developed dependencies.
  - lmm 9y ago
    I'd say rather: approach a dependency upgrade like any other code change, and be prepared to refactor aggressively (including by copying code and removing the dependency, if necessary) as with any other code change.