Elect Lodash Methods To Demystify ~ Log about 30-seconds-of-code

[sabareeshkk]

@Chalarangelo i am excited to try any one of these.

[feiwen8772]

@kingdavidmartins @Chalarangelo I really like this project! This project should be more popular than Lodash. This project is a collection of code snippets, not a library. More simple and easy to learn.

[kingdavidmartins]

@skatcat31 It's now Titled: Elect Lodash Methods To Demystify ~ Log

[Chalarangelo]

After 1.5 months of work, all the worthwhile methods from Lodash have been added as snippets in the repository. Huge thanks to everyone who contributed to this enormous project!

[Chalarangelo]

@kingdavidmartins I love you, man. I will start working through a few of these over time. This list is awesome. Hope we see it to completion eventually!

[Chalarangelo]

I believe lodash's slice and reverse are pretty much polyfills for older browsers. We should not implement those.

[Chalarangelo]

@kingdavidmartins I tried to clean up the log by marking the natively implemented functions, as well as the ones I remember that we have implemented already. We seem to be about 30% through it, which is very impressive for just one week!

[kingdavidmartins]

Hey @skatcat31 👋 Yea no problem.

That's a fair question. Hopefully my response helps.

The key word here is demystifying. By demystifying I mean exposing all their methods/function in a way that is easy & simple for the everyday/beginner programmer to understand. As amazing as lodash is, it isn't a simple feat to read through and understand all of lodash methods for your everyday/beginner. Especially when a lot of their method re-uses a lot of their other methods and/or other libraries. The goal here is to have users just find a snippet similar to lodash's snippet and say "ahhhh ok I kind of get it" or "hmmmm I wonder what Array.from() is why not use Array.apply()" or even "What if I just tweak x or y".

This is very important because it's simple and the barrier to entry is low. Someone just getting started can understand our snippets fairly easily. So why not expose them to one of the most used methods in our industry?

Think of demystifying lodash as a way to creating a beginners guide to lodash methods or understanding lodash guide in 30 seconds or less. I definitely think it not only adds value for Non Traditional who don't have a CS degree or are switching from a dying industry and trying to learn/understand new methods they have or haven't used. But also adds value for the kids in elementary/middle/high school who have just finished or started a codeacademy JavaScript course. None the less I don't think continuously working on the demystifying lodash backlog negatively impacts the projects.

@Chalarangelo Thoughts?

[Chalarangelo]

@kingdavidmartins Great explanation on why we are doing this. @skatcat31 my two cents on the matter are as follows:

• Tools like jQuery and Lodash are industry standards and people use them without knowing their inner workings. Many developers on SO for example feel like jQuery is some kind of voodoo magic that cannot be done with regular JS. We need to show them otherwise!
• Lodash has a ton of useful functions that I would want to use in a project, but I avoid adding huge libraries when I can help it and I like learning how their guts work, so I can modify them. Therefore, it provides us with a great opportunity to implement useful and commonly used methods for people who want to understand how it works and want to hack them a little bit, see what they can make of them.
• As far as it has been discussed, we are not going to be building a library out of this, unless demand is extremely high. In that case, we might make a secondary project that releases every month with stable and well-tested snippets. Definitely do not bet on that, though.

TL;DR: Lodash is a great starting point and new contributors know what to build and what the expected functionality is, plus we know that the methods we are implementing are useful and we do not have to figure out if they are a good fit in term of usability or not.

About voting: I believe in community moderation and decisions, so I'm very glad that we can now decide which methods we do not want. For me the rule of thumb has always been that if something is natively implemented, we do not rewrite it (unless we extend functionality). That being said, we have a bunch of isX() methods that contradict my statement. Kindly suggest what we should be doing with them in the comments below.

[mycaule]

Other libs to consider among many others:

• String: https://vocajs.com,
• Date formats: https://date-fns.org,
• Functional programming: https://ramdajs.com

With ES6 you can import only some of the functions, which allows developer to pull a banana
from the tree without pulling the whole jungle. If I want to use these functions in production I would rather use a popular library than reinventing the wheel.

All these libs are working on more ES6-ish implementation.

You might need to make a difference between a collection of utility functions and just pure exercises. Like a teacher you need to select just the interesting ones so that the student doesn't have to go through all the textbooks. The goal is also to teach the student of JavaScript features.

Some good references of teaching with examples:

• JQuery: http://youmightnotneedjquery.com
• ES6: https://github.com/mbeaudru/modern-js-cheatsheet
• Regular expressions: http://sed.sourceforge.net/sed1line.txt
• One line modules: sindresorhus/ama#10

[Chalarangelo]

I think that the set, unset, setWith, update and updateWith methods in Object are nearly impossible to implement without making assumptions or writing really bad code or code that is hard to explain. I vote to skip those entirely!

[kingdavidmartins]

@sabareeshkk Yea give some of them a shot. Hope you submit a PR 😄

[skatcat31]

So something that's been bothering me: why are we demystifying lodash?
We aren't, nor should we try to be, a replacement. We are more a place for people to learn cool tricks in small snippets aren't we?
IFF we wanted to be a library we would need to be MUCH more structured about our approach to development, and pull requests, and implimentation( ala Ramda, Lodash, and other libraries that allow community support )
If we want to do such a series, why would we do it here? It'll add a lot of previous arts to questionable gain IMHO.

[kingdavidmartins]

Hey @feiwen8772 👋

Aww Thanks 💯 ❤️ This means soooo much. This project is made possible by @Chalarangelo & all the other contributor's that worked so hard making it all possible. You included 😉

Thanks again 😄

[fejes713]

@Chalarangelo Agree, plus we don't have to copy the whole Lodash 👍

[Chalarangelo]

I think we are reaching a point where we need to decide what we want from the leftover stuff from lodash. There's definitely plenty of stuff we could really do without.

On the subject of the ones I mentioned, I am marking them off in the log so that we can work on others.

[meetzaveri]

So should we start picking one by one from these resource to contribute new snippets? Is that you saying @Chalarangelo

[Chalarangelo]

@meetzaveri yep, let's ge started. Follow the guidelines in CONTRIBUTING.md to make merging PRs easier, work on individual files and state here which ones you intend to write (even though you might not), so we don't end up with duplicates if possible. I am clearing up PRs right now, will try to chip through some of the methods listed here later today.

[sabareeshkk]

@kingdavidmartins sure will do 👍

[Chalarangelo]

@kingdavidmartins I think we have https://lodash.com/docs/4.17.4#difference implemented under array-difference.md.

[kingdavidmartins]

@Chalarangelo if there is any snippets I am missing please let me know. I kinda was up all night so not as sharp as I should be. Later on after some rest I should have all the current snippets that have been implemented updated and extend the list to include the Collection, Lang, Date, and Function section/category

[Chalarangelo]

Alright, I'll see if we have any of them and I will also get coding now that the PR list is almost empty.

[Chalarangelo]

I updated some the list with some of the changes made and implementations added, also moved all completed functions to the very bottom to be easier to find new things to implement at first glance.

[Chalarangelo]

By the way I am sticking to the same PR procedure as everybody else for at least some of these snippets, so that I can get feedback before merging them in. Otherwise, we can easily lose track of what's going on.

[fejes713]

@kingdavidmartins & @Chalarangelo are we going to create a library out of this? 😄

[Chalarangelo]

@feiwen8772 In all honesty, I don't know. When we're done with Lodash's implementations and the PRs stop coming in so fast, we should look into packaging everything, seeing if people want that. For now, it's a bit out of the scope of the project and there's so much else that needs to be done that we can put that idea on hold for the next month or so. But it keeps coming up all the time, so we will eventually have to discuss that.

[skatcat31]

While it present a great learning opportunity, if they're at that level of beginner that they can't understand lodashes documentation and some of it's source code I fail to see how we could make it clearer. For some lodash or other library methods that could use an easier to understand version I totally agree.

[kingdavidmartins]

Maybe instead of demystifying all of lodash, elect which ones to demystify

I def agree with that statement. To date there have been quite a few methods/functions we haven't really touched and have elected to not implement For example _.map because it's natively supported

@skatcat31 You can also proactively look for snippets/methods on the log you think we shouldn't implement. Which the collaborators/community can vote on in agreement or not

[skatcat31]

@kingdavidmartins That makes my complaint null if we can vote on what to not do. The question then becomes "How do we vote?"

[Chalarangelo]

@mycaule Truth be told we are working on Lodash, as it was the easiest/closest to our scope. Ramda is something that has been mentioned before and we might dissect a few of its methods, while jQuery's demistification is something I personally wanted to work on these past few days.

Overall, we are trying to find as much worthwhile material and convert it to our structure, so that people can learn as much as possible and understand their tools

[mycaule]

Lodash isn't mystifying anything, original library underscore.js even has annotated source, and developers could always look directly at source code if any doubt.
http://underscorejs.org/docs/underscore.html

Paul Irish on JQuery is good resource too: https://www.youtube.com/watch?v=i_qE1iAmjFg

Need to find purpose to that repo. It is great as a teaching material or for interview questions for example. Comprehensiveness might not be necessary, you will not be able to achieve it anyway.

[skatcat31]

@mycaule yes they can read through it, but it's often easier to see a simple short example than traversing their 1K+ lines of code in those libraries. I constantly implement features of Ramda in vanilla ES6 because I don't want to have to import the many helper functions they use. While not a hit on performance, I don't want a front end to have to load their entire packages for a single function only to discard most of it. If I can use a packager or a smaller version, I often elect to do that.

As for the lessons features we do have the Adapter category right at the top which shows some useful functions. We do need to clean up their descriptions though and put compose into that category as well with a description that states why they would use compose over pipe( algebriac transformation order versus lexical reading order are easier for people to understand based on the context ).

Truth be told once we're done cleaning this up, a longer "lectures"/"examples" namespace might be and interesting extra page of learning materials for people to use.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for any follow-up tasks.