meta tags manager

[justin808]

No description provided.

[justin808]

@josiasds Let's consider the lodash syntax from this.

Interesting find from @dylangrafmyre on the CI regarding Array.from.

[josiasds]

@justin808 I'm not sure we should add lodash only to replace Array.from by _.toArray.

[justin808]

You're right. We don't have lodash in this project.

_.find(document.getElementsByTagName('meta'), tag => tag.name === 'csrf-token')

or

_(document.getElementsByTagName('meta')).find(tag => tag.name === 'csrf-token')

I really like Lodash. I wouldn't suggest this otherwise. That being said, we don't need it give some features in ES6.

Because I want this example to be a real starter kit showing off Webpack/Npm/React integration, I think this is worth considering.

Let's see what @mapreal19, @alexfedoseev, @samnang, @dylangrafmyre Think about this one.

[justin808]

Even better from the lodash source, @jdalton:

_.find(document.querySelectorAll('meta'), 'name', 'csrf-token')

[justin808]

@josiasds We can consider adding Lodash in a future PR.

[josiasds]

@justin808 👍

[justin808]

See #124

[alex35mil]

My decision making chart:

Can I use Immutable.js in this project?
            ⇙           ⇘
         Yes             No
       ⇙                    ⇘
Immutable.js               Lodash

[justin808]

@alexfedoseev Why would you avoid lodash if you're using immutable.js? We're already including lodash through a dependency of dependency.

[alex35mil]

Because every Immutable instance already has all necessary methods in its prototype to handle the data transformations.

[alex35mil]

Btw, in this case it's better to use not npm i --save lodash but npm i --save lodash.find to include only actually used lodash's method & reduce total build size.

[jdalton]

require('lodash/collection/find')

[alex35mil]

@jdalton 👍

[justin808]

@alexfedoseev do wepacks optimizations strip out unnecessary libs?

[jdalton]

If you cherry-pick, then yes.

[justin808]

@jdalton by cherry pick, you mean with the

require('lodash/collection/find')

and can we include npm i --save lodash or do we need to do npm i --save lodash.find

Incidentally, this project is already including lodash as a dependency of a dependency.

[alex35mil]

and can we include npm i --save lodash or do we need to do npm i --save lodash.find

If we'll do npm i --save lodash, then we can:

import _find from 'lodash/collection/find';

If we'll do npm i --save lodash.find then we can:

import _find from 'lodash.find';

Result will be the same. Only difference is if lodash will be installed, then we don't have to add stand-alone modules to package.json (like lodash.find). We can just cherry-pick them from lodash/collection dir.

@jdalton correct me if I'm wrong.

Incidentally, this project is already including lodash as a dependency of a dependency.

I don't think it's a good idea to rely on such dependency, because we can't control it (it can be changed or removed from this package in the future versions). We should define this dependency implicitly. If lodash packages will be identical, then webpack.optimize.DedupePlugin should handle it.

[rstudner]

Immutable.js > Lodash if we are talking about going into the future. (I love lodash, that isn't the point)

That being said, if we are going to use lodash, we 100% have to explicitly depend on it and not rely on a 3rd party library pulling it in.

[jdalton]

Immutable.js > Lodash if we are talking about going into the future.

[justin808]

👍 👍 👍

@jdalton it would be nice if there was some way that we could use Lodash API's with immutable objects. We're prefixing the names of our immutable objects with $$, like $$users to indicate a immutable list of users. We ran into many bugs from forgetting to use the Immutable rather than the native JS APIs.