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
How many classes/functions are best put into a module (which is later required, f.ex. by RequireJS, the Mozilla addon loader, ...)?
As the module seems to be imported wholesale (contrary to f.ex. Python, where you can do from module import class), would it be best to keep them as small as possible? Any other guidelines?
What is the best practice?
(There are similar questions about Java (which recommends "the more granular class layout you have, the better"), Python (which allows for more objects and states "Python is not C#/Java. Trying to bend it to make it look like $other_language will cause frustration and poor user experience") , etc, but nothing JavaScript-specific appeared.)
Maybe these questions were old enough to pass the site standards then. Nowadays, it might be really too broad for some.
I personally do the following when using RequireJS:
One class per module
Module file named after the class name
This allows for easy maintenance, plus dynamic loading of the needed classes.
Only drawback could be the amount of files, but you can bundle the ones most used later using RequireJS optimization features.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
hi my friends I have a question
how can I create multi language site with Nuxt?
my site is ssr and I don't want use any package beacuse client wants to me handle this without package
Not sure why you don't want to use the i18n package but as told before: You can create your own solution with some vanilla code I guess.
IMO, you will lose quite some time doing this. I'd prefer to use a package who does that well rather than trying to achieve it myself because I'd probably bump into un-expected edge cases.
You can always get inspiration from the i18n module source code itself but then, why not use it directly. Using a battle tested package in the JS world is not a bad idea. Especially if it's mantained well (by Pooia).
Reminds me of this one: https://imgs.xkcd.com/comics/standards.png
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 found my former collegue comment like:
// TODO: Get rid of it. Don't expose to other modules.
export * from './search.actionTypes'
export * from './models/ISearchState'
export * from './models/ISearchFilters'
My question is:
It is bad practice to expose submodules on JS? Or maybe it is related to code style and depends on a community practice?
It is bad practice to expose submodules on JS?
Absolutely not. Note that "reexporting" is different from "import than export". It just creates a reference of the exported name to the import, and leaves the way the modules are loaded up to the actual implementation.
That means, that if you use a bundler such as Webpack, it will "inline" the final import, so there is no difference wether you directly import from the original module or from the module that reexports it (except you are using a wildcard import, that will always be bad for treeshaking).
Or maybe it is related to code style and depends on a community practice?
Splitting up larger functions / classes into different files keeps things clean, and through reexporting you can create a unified import for your package (i.e. reexport everything inside index.js, then you can import {x, y} from "/module/";). Wether to split up code into multiple files is your personal choice, there is no universal rule.
"TODO: Get rid of it"
Your colleague has a better overview of the project, so he might see things that we don't. He probably has a good reason to write that comment, I would ask him for his exact reasoning (maybe the exports are never used, or should be kept private by purpose ...).
That said there is one downside of wildcard reexports: If you import, you won't know where the function imported came from. You should always prefer named exports.
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 5 years ago.
Improve this question
My company have a really big application, with a lot (!) of data.
We have an argument using 3 modules for the main areas, and the main as flat module in store,
or using sub-modules as much as needed. (for each main sub-module about 6-8 sub-modules)
I wanted to get opinion only from people with experience in complex application using vuex.
Is it better to keep the module flat? or to use sub-modules?
Pros vs Cons
If you go by separation of concerns, It really makes sense to have submodules for different part of your system. It makes the feature enhancement easy and adding in one submodule does not alter anything in other modules, which makes collaboration also easy with different people working on different modules of your application.
Vuex submodules also helps keeping states of different submodules isolated from each other, otherwise it is too easy to have all the state variables mingled among each other. it implicitly emphases this discipline.
But in case your application is very simplistic and it is too much trouble to separate those in different submodules, than it will be definitely a overkill to use submodules.
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
At the moment Im using a bunch of script elements which are referring cdn/local files which is not so great.
I think I would like to declare all required packages using npm/yarn and serve cdn files with self hosted fallback (is this even a good idea?).
Should i go for a webpack/browserify solution or is this overkill for this purpose (because AngularJs is already handling dependency injection by itself)? Im getting somewhat lost in the amount of frameworks/information about this topic.
This is an opinion question, so we can only try to figure out what we would do given our knowledge of your needs. With that grain of salt:
What you are describing sounds like way overkill. Unless your performance needs are huge, manage your dependencies with npm and package them with your releases. If you really need to, use a build tool to minify and package your resources together (like webpack).
There are tons of great JS build tools, and if all of the boilerplate is overwhelming, take a look at something like Yeoman which can help out with that.
In my opinion, a self hosted CDN is probably the worst option possible, because it adds huge support requirements with almost no benefits, because as soon as you stop caring about this project someone else will have to refactor all of your code to new CDNs or local resources.
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 9 years ago.
Improve this question
I come from the Java/C# world where namespaces are absolutely necessary. However, comments like these make me think that modules are of no utility in typescript (and javascript). For large typescript/javascript programs (probably several hundred .ts/.js files by the time we're done), are modules a good practice or do they just get in the way?
ps - I know that opinion questions are not allowed here. But, IMO, this is more a "please explain how javascript works" question.
Having a deep namespace hierarchy is mostly an overkill. Having a single top level namespace is definitely a good idea though.
e.g.
module appName{
class Foo{}
}
instead of
class Foo{}
But not so if you are using already using external modules (commonjs / requirejs) as they isolate code for each file.