Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Has anyone implemented Underscore or Lodash into their existing AngularJS project for a performance boost? If so:
Were the changes something noticeable or something that you would recommend?
Which functionality from Lodash did you find the most benefits?
I have not actually played with Lodash before and was looking into learning it. But I typically like to learn something and then actually use it shortly after, so that the concepts stick better. If I'll get some good benefits out of implementing Lodash, then I think it would be a good time to learn it now.
I do typically need to perform functions such as filtering or finding an object inside some sort of collection, so I'm thinking that's where I would utilize it the most.
Well they have really different purposes.
Angular is to build an application. It helps you to structure your code and separate responsibilities between your components (modules, controllers, services, directives, routers).
Lodash is nice to manipulate collections, arrays, objects, strings, etc. It helps your code to be shorter, cleaner and probably faster. It is really well tested and documented. In my opinion, it makes your job simpler.
I use Lodash for 4 years now. I found it useful in all my projects (Backbone, Angular, JavaScript, node, in the unit tests, in the build configuration files (Grunt, Gulp, Webpack)).
PS: Lodash is also a must-have to go into functional programming in JavaScript.
Edit: Example of searching that you can't easily achieve without Lodash
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I’ve been working with JavaScript for around 4 years. In all the applications I’ve worked on, I’ve never once seen someone use a linked list. Why is that? Data structures are so prominently featured in most learn-to-program courses. Yet I almost never see them used in the real world.
This may not be the perfect explanation of this but I think will give you a fair idea about it.
The scenarios which will make sense to use Linked list on JavaScript
are very rare. You have been working on JavaScript for 4 years when
did you feel a need to use linked lists and not JavaScript Array
The main purpose of using linked list is performance improvements,
when there a is a huge collection of records and frequent changes to
them linked lists help in optimizing that. But that case may not be
true for most of the JavaScript applications. Arrays are pretty much
bale to do that for JavaScript.
Most of the frameworks rely on array's be it React, Vue etc.
In case of linked list methods like unshift, etc. are much faster.
while methods on Arrays, such as push, run considerably faster than
Linked Lists.
The use of linked list is justified when you need to make a lot of
modifications to a huge list — especially when adding or removing
items somewhere other than the end of the list and such cases are rare in
JavaScript/front end.
Last but not the least JavaScript has great support for Arrays but
you will have to code your own implementation or use some library
that provides linked lists implementation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I understand the concept of a react/redux app.
My question is, is there a preferred way to layout the folder structure and files.
After doing much research of repos online it appears that everyone does it slightly differently depending on their code flavor.
Angular on the other hand appears that there is a set structure.
Is this what makes react more powerful as you can tweak and adjust as your needs change?
Has the community agreed on any set patterns?
As you said yourself; 'Everyone does it slightly differently'. It can help to give some resources right?
I don't know how much experience you currently have with React. I personally started with a traditional structure that made use of the dumb / smart component pattern, in which I created a src/redux folder. Within that I had an actions + reducers folder. This works fine for smaller applications.
I changed that approach after learning about the Redux Ducks pattern, which removes a lot of boilerplate and copy-pasting reducers.
I'm currently using this structure.
My suggestion is to try different approaches and see what works best. It depends on how you and your colleagues work in general. For example - if you know that everyone uses their CMD+P to search for specific files, you'd prefer being more explicit in file names, instead of having an actions/posts.js and reducers/posts.js file you'd prefer creating postsActions.js and postsReducers.js instead. I'd suggest reading these two Medium posts aswell, as inspiration:
My journey toward a maintainable project structure for React/Redux
How to better organize your React applications?
Edit on 31 july 18:
Seeing as a lot of people still read this comment and upvote it. I would like to recommend that if you're starting to work on a medium to large project, I would definitely try and get some knowledge about TypeScript and React. I've completely migrated to TypeScript as it makes it a lot easier to step back into a project after a while due to typings, interfaces, generics, and it being more strict. It greatly helps for your overview of the project. Several downsides of it is that you have to learn the typings of the React library and how to use this. TypeSearch greatly helps to see if there are typings available for a specific library. Also some patterns like higher order components can be awkward in TypeScript due to typings at first.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am diving in MongoDB and MapReduce. You known JS language is verbose and not complete. MongoDB has more scarce JS that browers e.g. I just found that there is no "Objects.key" method. I'd like to ask for directions about JS libraries mitigating this boilerplate code for extracting keys, values into arrays and rest tasks with collections.
I tried to google such class of libraries but without any success.
Your question isn't very clear. The native JavaScript mongodb driver uses a json-like query syntax and the results are standard JavaScript objects and arrays which may be traversed using standard JavaScript. JavaScript by the specification is a very mature language, though often confusing for developers who are not familiar with prototypical inheritance.
If you are looking for a JavaScript utility belt to allow you to work with the results, I'd recommend lodash. If you want to add schemas and other traditional database features, have a look at mongoose. I prefer to use the native driver since you can do more dynamic things with low overhead.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I see a lot of Javascript frameworks created recently since I've been learning web development (http://www.infoq.com/research/javascript-frameworks-2015). Do you know what kind of knowledge you need to know in order to create a Javascript framework in particular or any framework in general?
Creating a JS (or any other kind of) framework isn't something done easily, but some of the steps include:
Find a niche where no framework exists yet or doesn't cover a specific use-case, and where you have good knowledge of the problem space
Design and implement an easy to use (and, if required, future-proof) API
Publish it, e.g., on GitHub and advocate for it with a website or through blog posts
Maintain it
Hence, you'll need to know how to design good APIs, reasonable JS knowledge to build them and patience.
Note: while the initial fun starts with building out something, releasing and maintaining an actual framework is far more complex and requires time and effort - especially to build a community and once these users start requesting additional features, or your initial design considerations fall short of the new use-cases imposed by real-world usage. You can always build something and publish it to NPM, but be aware that maintaining a project in the open source community involves more than "writing code", and deprecating or deleting a framework/package can yield surprising results.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Where I was working as an intern, working on a JavaScript front end project with Backbone.JS, I was using those getters and setters as provided by the framework (Backbone) but was asked to define my own to make it clear whats public/private. I was more for using those provided by the backbone. Whats the better practice or recommended method here?
Then recently, I was developing my own ExpressJS/Mongoose app, I started off thinking I define a Todo model then a Todos collection that exposes functions like byId, byList etc, but then I was thinking perhaps I should just use those provided by Mongoose?
The advantage of using the provided getters/setters will be
Less code, less bugs
standard way of getting/setting. Instead of 2 (from framework + custom)
Another developer will just need to learn the framework instead of my custom code to understand whats happening
Cons:
a little longer code
less sense of whats private whats not, but I think this is not very important ... esp in a dynamic language
Again, whats recommended here?
If the framework allows it to you, write your own getters/setters only when you have to modify the behaviour of the default getters/setters.
There's no reason to write them if not needed, IMHO.