Develop Reference

loading external javascript libraries

I'm trying to deploy on a live server a small flask app that also uses javascript and some Three.js library files. When trying to import the required three.js files in my app.js file I get the 404 resource not found error. I'm using a digitalocean droplet and the folder structure is as follows:
app
├── __init__.py
├── static
│ ├── css
│ │ └── style.css
│ ├── js
│ │ └── app.js
| | └── three(folder with all the three library files)
│ └── models
│ └── poly_ann.glb
├── templates
│ └── index.html
└── views.py
the app.js is of type "module" in index.html. the top of the app.js looks like this:
import * as THREE from '/js/three/build/three.module.js';
import { GLTFLoader } from '/js/three/examples/jsm/loaders/GLTFLoader.js';
import { DRACOLoader } from '/js/three/examples/jsm/loaders/DRACOLoader.js';
import { GUI } from '/js/three/examples/jsm/libs/dat.gui.module.js';
.
.
.
needless to say that as a pure html/javascript app on my local server these paths works just fine.
As you can see the app.js file is sitting inside the static folder as all the tutorials suggest.
The problem is pathfinding of three.js libraries. the three folder is sitting inside the js folder but it's not finding it for some reason.
Any help will be appreciated.

It would be usefull to post the exact error but sometimes it help if you add a . before the slash, for example import { GUI } from '/js/three/examples/jsm/libs/dat.gui.module.js';
becomes import { GUI } from './js/three/examples/jsm/libs/dat.gui.module.js';

How to segregate page components into several `/pages` directories on a Next.js app

I recently started my first project with Next.js and since then my pages directory has grown a lot. Now I want to separate my pages and group them into modules, ending up with something like 'src/modules/*/pages/*'.
Researching the topic I came accross exportPathMap, a function that I can include in my next.config.js file and then map custom paths to my pages, but it seems like I'd need to add a new path for every page I create, which is not ideal. I want to give to Next a single expression, something like 'src/modules/*/pages/*', and let it resolve the pages and routes for me (like you would do in a ormconfig.json file to map entities when using TypeORM).
I suppose I could group my page components directly inside pages, like pages/a-module/*, but I also have components, hooks and other logic that I'd like to segregate into modules. I could also try using Node's fs to iterate through my project file structure and map the the page folders, but I'd like to avoid that if possible.

You could use symlinks. You would need one for each module, but not one for each nested path within the module. Your directory structure would look like:
├── modules
│ ├── bar
│ │ └── pages
│ │ ├── first.js
│ │ └── second.js
│ └── foo
│ └── pages
│ ├── first.js
│ └── second.js
├── pages
│ ├── _app.js
│ ├── bar -> ../modules/bar/pages
│ ├── foo -> ../modules/foo/pages
│ ├── index.js
Which would end up with routes:
/bar/first
/bar/second
/foo/first
/foo/second
I'm not sure what that buys you, though, really. Now your modules folder will have the same clutter that pages used to. You don't have to have all of the component content in the files in pages. It could be as simple as:
// pages/foo/first.js
import FirstContent from '../../modules/FirstContent'
export default function First() {
return <FirstContent />
}

As #Roman Mkrtchian mentioned, you're not supposed to do so. My suggestion is that, if you want to organize your files into modules like me, creating a file structure similar to this one:
src
├── modules
│ ├── foo
│ | └── pages
| | ├── one
| | | ├── index.jsx
| | | └── styles.js <- For `styled-components`; could be a css file
| | └── two
| | ├── index.jsx
| | └── styles.js
| └── bar
| └── pages
| └── three
| ├── index.jsx
| └── styles.js
├── shared
└── ...
You should take another approach. As #erich2k8 said, you don't need all of the component content to be in the files inside /pages, you could create the same structure above, but add /pages directly to src:
src
├── modules
├── shared
└── pages
├── foo
| ├── one.jsx
| └── two.jsx
└── bar
└── three.jsx
And inside src/pages/foo/one.jsx, for instance, you'd import src/modules/foo/pages/one, like so:
import OneContent from '../../modules/foo/pages/one';
const One = () => <OneContent />;
export default One;
Yes, you'd still need to create a new file for each page you create inside /modules, but it spares you from a really bad time messing with Next behavior.

This is not permitted by the Next.js team on purpose for reasons explained in this post and in the posts referenced there.
You may read some of the discussions before deciding if you really want to hack the files structure to do it anyway.

Nuxt multiple dynamic page param /slug

I have a /post/:id route that works and I need to create a /post/:id:/edit route. How do I do this with Nuxt's dynamic pages setup. This is what my pages directory looks like:
└── pages
└── post
└── _id.vue
Documentation does not seem to mention this case, how do I do this ?

Directories can be _id too, change _id.vue to index.vue like:
└── pages
└── post
└── _id
└── index.vue
└── edit.vue
Example: https://codesandbox.io/s/amazing-wozniak-ekpw3

How do index.js files work in React component directories?

I just started a new React project and decided to use this pattern, which basically groups files according to their respective component:
├── actions
│ ├── LaneActions.js
│ └── NoteActions.js
├── components
│ ├── App
│ │ ├── App.jsx
│ │ ├── app.css
│ │ ├── app_test.jsx
│ │ └── index.js
│ ├── Editable
│ │ ├── Editable.jsx
│ │ ├── editable.css
│ │ ├── editable_test.jsx
│ │ └── index.js
...
│ └── index.js
├── constants
│ └── itemTypes.js
├── index.jsx
├── libs
│ ├── alt.js
│ ├── persist.js
│ └── storage.js
├── main.css
└── stores
├── LaneStore.js
└── NoteStore.js
What's confusing me is how index.js works in this case. As quoted:
The index.js files are there to provide easy entry points for
components. Even though they add noise, they simplify imports.
What the article doesn't do is go in depth of what's inside these files. In the case of the Editable component, what would Editable.jsx and index.js ideally look like?

This exact structure suggests that, for example, the Editable component would have everything about that component inside Editable.jsx. and I mean that your component code stays inside that file.
Now what's index for ? Inside index you would simply do something like this:
import Editable from './Editable.jsx';
export default Editable;
and that's it. This is helpful because inside other components or containers you can do this:
import Editable from '../Editable';
because it tries to access the index.js file by default thus not requiring any more info from you. It would import automatically the index.js file which imports the actual component itself. If you did not have an index.js file you would have had to do this:
import Editable from '../Editable/Editable';
which is kind of awkward. I don't like to have an index file that all it does is import a component and export it. What I usually do is just have all my component code inside the index.js file without the need of the Editable.jsx at all. That's up to you so feel free to take the approach you like better.

If one is using this directory per component pattern looking for a clean way to organize and access your modules, then the example above with a default export won't work with multiple files, e.g; this structure with a reducer directory:
── reducers
│ ├── todoReducer.js
│ └── filterReducer.js
│ └── themeReducer.js
│ └── index.js
├── components
├── App.js
├── app.css
└── index.js
So reducers/index.js would look something like this:
// index.js
import filterReducer from './filterReducer';
import todoReducer from './todoReducer';
import theme from './themeReducer';
export { filterReducer, todoReducer, theme };
...whether originally exported as default or named files in their original files, they are named exports now, and can be used cleanly in App.js as follows:
// App.js
import { filterReducer, todoReducer, theme } from '../reducers';
So we can avoid all this noise:
import filterReducer from './reducers/filterReducer';
import todoReducer from './reducers/todoReducer';
import theme from './reducers/theme';

You can also leverage it for module namespaces, e.g.
//MyNamespace/index.js
import Mod1 from './Mod1' //assumes ./Mod1.js
import Mod2 from './Mod2' //assumes ./Mod2.js
export{
Mod1,
Mod2
}
Then in other files you can import with a namespace:
//SomeOtherFile.js
import * as NamespaceToUse from './MyNamespace'
// Then access as:
NamespaceToUse.Mod1
NamespaceToUse.Mod2

There is no real benefit to using indexes for a front-end web application (whether written in React or not). If anything they are detrimental to optimal work on such project.
Organising imports should be automated and developer should not be concerned with it at all. Importing needed modules (component or not) can be automated by IDE suggestion (Intellij, WebStorm, VSC, all have those features), all you need to do is to start typing a Component's name.
Organising and optimising import structure can be done automatically on save via tools like prettier-plugin-organize-imports. There really is no need to manually interfere with imports, unless you have an import conflict.
Given that applications tend to grow, and future component folder structure is not deterministic, upkeeping of index files(dead weight) is an unnecessary overhead. Also most IDE's will open the index file instead intended Component if you ctrl/CMD click on a Component name, which is rather annoying and just distracts from you getting where you need to be (and if you need to write a lot of code, and need to look into dozens of components every minute, will become a real pain real fast).
Where indexes may be useful is, when you're writing a modular library (not an app), and you'd like to organise imports for the actual users of your library. You then also have the need of separating internal code from public/documented code. Libraries tend to have a more rigid structure, with clearer top level modules, which follow a specific segregation, which makes indexes less likely to be edited unless a new public/documented functionality needs to be exposed or deprecated. In this case indexes are useful, since they effectively create the interface for your library.
Based on the above indexes do not have a useful purpose in web applications source, but unfortunately they seem to be fashionable in some projects.

We currently have a component index file like this
/components/index.js
export { AutoCompleteInput } from './AutoCompleteInput';
export { AutoScrollWidgetRepositioning } from './AutoScrollWidgetRepositioning';
export { BrowserMessages } from './BrowserMessages';
export { CheckboxInput } from './CheckboxInput';
And a component index file like this
/components/AutcompleteInput/index.js
/* eslint-disable import/prefer-default-export */
export { default as AutoCompleteInput } from './AutoCompleteInput';
This means we can import components like this into other components.
/componnts/Form/Form.jsx
import {
AutoScrollWidgetRepositioning,
BrowserMessages,
HeadSection,
InitialWidgetLoadEventManager,
PageLayout,
} from '..';
This makes the import tree clean and tidy, however the downside of this, which i am currently finding out is that there are dependency cycle errors i.e. the import is importing itself, thus an issue. I am coming to the conclusion that index files may better be the actual component so the imports are not import { CheckboxInput } from './CheckboxInput/CheckboxInput' and stay as
import { CheckboxInput } from './CheckboxInput'.
TLDR: index files prevent an echo, but don't over use them else you may come across a cyclical import issue.

Nodejs: Good practice to just use the index.js to EXPORTS?

I am seeing a pattern on some code I have inherited. Each directory has its JS file but there is also a index.js that actually exports items from the other JS file or files.
I presume this is done so you can see exactly what you are exporting, as the main exports are in index.js and the main code is in the other js file or files.
Is this correct? What is this pattern called ?
Should I continue using this pattern.

Let's say I have the following directory structure:
MyApp
├── app.js
├── test.js
├── package.json
├─┬ controllers
│ ├── index.js
│ ├── signIn.js
│ └── signOut.js
└─┬ views
├── index.js
├── signIn.js
└── signOut.js
Placing the following code inside the index.js files...
// index.js
module.exports = {
signIn: require('./signIn')
, signOut: require('./signOut')
};
...allows you to require an entire directory like...
// test.js
describe('controllers', () => {
// ~/controllers/index.js
const controllers = require('./controllers');
it('performs a sign-in', () => {
...
});
it('performs a sign-out', () => {
...
});
});
The alternative is to require each file individually.
Having an index.js in a directory is not required. You may require a file in a directory without an index.js all the same.
// app.js
const signOut = require('./controllers/signOut.js')
However, it gets tedious as your app grows. I use a package like require-directory as typing out each file in a directory is also tedious and somewhat error prone.
// index.js
module.exports = require('require-directory')(module);
/*
This yields the same result as:
module.exports = {
signIn: require('./signIn')
, signOut: require('./signOut')
, ...
};
*/

ES6 CommonJS Module syntax
Given these two common types of structures...
MyApp
│ // files divided per type (controllers, components, actions, ...)
├─┬ actions
│ ├── index.js
│ ├── signIn.js
│ └── signOut.js
├─┬ components ...
├─┬ reducers ...
├─┬ pages ...
│
│ // files divided per component
├─┬ components ...
│ ├── index.js
│ ├── SimpleComponent.jsx
│ ├── AnotherComponent.duck.jsx // redux "duck" pattern
│ ├─┬ ComplexComponent // large complex logic, own actions, stylesheet, etc.
│ ...
├─┬ pages ...
│ ├── index.js
│ ├─┬ App
│ │ ├── index.js // not necessary here, matter of habit
│ │ ├── App.jsx
│ │ ├── actions.js
│ │ └── reducer.js
│ └─┬ Dashboard
├── another.js
...
You can simply import files in another.js like this
import {signIn, signOut} from './actions'
import {App} from './pages'
import {ComplexComponent} from './components'
instead of this (without index.js files)
import {signIn} from './actions/signIn'
import {signOut} from './actions/signOut'
import {App} from './pages/App/App' //notice the redundancy here
import {ComplexComponent} from './components/ComplexComponent/ComplexComponent'
More reading
ECMAScript 6 modules
import - JavaScript | MDN
Babel transpiler - brings the new imports to your browser now
Structuring React projects
React Redux "Ducks pattern" - a single file approach for components

The other answers provide a lot of great information, but to try and specifically answer your question 'Should I continue using this pattern", I'd say no, at least most of the time.
The thing is, this pattern requires extra effort, as you have to maintain those extra index.js files. In my experience that effort is greater than the effort to simply write one-directory-longer import statements. Plus, you can get the same functionality you'd get from having an index.js without one, by using a module like require-dir.
All that being said, if you are making a library that will be consumed by a large number of people, like a critical module in a large programming department, or a public NPM module, then the effort of an index.js becomes more justified. As long as you have enough people using your modules, your users will (cumulatively) save more time from you adding them than you will lose maintaining them.

I will directly dive into your question on whether to use this pattern or not (as other answers are not sufficient for this).
Assuming that each directory in your code represents a standalone module (doesn't rely on another module to work). Using this pattern will give these advantages:
Better and more organized imports
Separation between internal/external definitions of each module (similar to using private/public on an interface/API)
The problems with this:
It can be very tiresome to keep loose-coupling of the different modules (JS/TS is not pure OOP)
Requires active refactoring to modules definition - more circular dependencies.
Loads more code to memory (even if unused) - though I'm not sure how bad this can be as there are optimizations that usually fix this problem when bundling production code.
Circular dependencies are very problematic, importing the whole module/directory using index.js will import all of its parts (that are declared in index.js) so if you have:
-- moduleA
├-- comp1A // needs comp1B
├-- comp2A
└-- index.js // export both comp1/2
-- moduleB
├-- comp1B
├-- comp2B // needs comp2A
└-- index.js // export both comp1/2
Example case - comp1A needs something from comp1B while comp2B needs something from comp2A
When importing the specific files (without index.js - import something from './moduleB/comp1B') you won't have circular dependencies.
But if you use index.js (import something from './moduleB') you will have circular dependencies.
My recommendation is to use index.js in the right places, and to keep those maintained! Using index.js with small modules will be perfect, but with time they will grow and should be divided. index.js is very bad to use in common/shared/utils/misc/core (whatever you call it when you want to put uncategorized and unrelated code that is used across your whole project) module.

What about this?
module.exports = {
...require('./moduleA'),
...require('./moduleB')
}
(moduleA.a will be overridden by moduleB.a)