How do next.js applications optimize for mobile screens? - javascript

I just figured out that since I built my app with Next.js, I can't use CRA's folder structure framework to build or diagnose my application.
Unfortunately, I'm completely at a loss at the moment with respect to how Next.js applications are supposed to properly scale a website for mobile devices. I've always been under the impression that it was the job of index.html to do that (which I've written, but my app can't seem to bother to find it or use it). I've looked at the default folder structure for a Next.js app:
├── README.md
├── components
│ ├── head.js
│ └── nav.js
├── next.config.js
├── node_modules
│ ├── [...]
├── package.json
├── pages
│ └── index.js
├── static
│ └── favicon.ico
└── yarn.lock
source
but there doesn't seem to be a place for index.html.
My question is simply, how do Next.js apps optimize for mobile screens? Are they even supposed to have an index.html, and if so where? And how do favicons work, because I've created the static folder and put the favicon inside, but I'm pretty sure to have the favicon do anything, it has to be referenced by a file (conventionally index.html).
repo

Next has this Document component which you can customize to your own likings.
As their official docs say:
Is used to change the initial server side rendered document markup
You can use it to customize your head tag content as you would do anyway in your index.html.
Don't forget to add <meta name="viewport"content="width=device-width, initial-scale=1.0" /> in head tag if you want your app to use media queries.
Next project is not supposed to have a particular index.html file. Instead, the initial page is supposed to be a component located specifically in pages/index.js.

Related

Link to static HTML page from within Svelte component

How can I move from a Svelte component to an HTML file using window.location.href?
I tried various combinations, but the HTML can't be found. Do I have to set up routing?
Folder Structure:
project
├── example.html
├── svelteProject
├── src
├── App.svelte
The most ideal thing would be to use Sveltekit. You could also try to create a full page iframe, not sure how you'd reference your HTML file though.

Typescript: resolve relative import path when using symlinks

This seems like a dumb question, but I struggle to find the answer.
The situation
Here is my folder structure:
myProject/
├── module1/
│ ├── config.ts
│ └── init.ts #symlink
├── module2/
│ ├── config.ts
│ └── init.ts #symlink
└── symlinks/
└── init.ts # the real not duplicated file
The file init.js import local files like so:
import config from './config'
// ...
The problem
The problem is that typescript throws Cannot find module './config' or its corresponding type declarations
I tried playing with typescript option preserveSymlinks but it didn't solve my problem
I know about other ways to achieve my goal but it's overkill for just one file and it doesn't solve relaying on a relative path (like creating a npm module, creating a function and pass relative file content as parameter or even generating files at runtime...)
=> I am working with typescript in a monorepo.
Is it possible to use symlinks this way? If no, are there other (simple) alternatives?

How to enforce deployment order with Complex TurboRepo requirements

Is there a recommended way to enforce deployment order via specific apps using TurboRepo? I know you can specify that all child dependents run first, but that results in undesired behavior in my scenario.
Here is an example of my file structure:
├── apps
│ ├── backend
│ └── web
├── packages
│ ├── assets
│ ├── config
│ ├── design-system
│ ├── hooks
│ └── utils
And here is the command I'm running to deploy:
yarn turbo run deploy:ci --filter=...[origin/main] --dry-run
In my scenario, I'd like my apps/backend to deploy before apps/web because web relies on output from the backend. I thought about using the following turbo.json:
{
"$schema": "https://turborepo.org/schema.json",
"baseBranch": "origin/main",
"pipeline": {
"deploy:ci": {
"dependsOn": ["^deploy:ci"],
"outputs": [".sst/**", ".build/**", ".expo/**"]
}
}
}
However, while this works if I add backend as a devDependency of web, it also results in backend always being rebuilt (even when none of its dependencies have changed). This is because if I change packages/hooks (which backend does not rely on), it will try to deploy packages/utils because hooks uses the utils package. This waterfalls and causes it to try to deploy backend because backend uses utils.
I'd also like to note that only the apps/* contain deploy:ci methods, so there is really no need for it to try to deploy changes to any package/* dependencies.
My end goal would look like the following:
Change packages/hooks
Detect change in packages/hooks and trigger deploy:ci for apps/web (which has hooks as a dependency)
Or
Changes packages/utils
Detect change in packages/utils and try to deploy both apps/backend and apps/web because they both rely on utils
I've tried replacing
"dependsOn": ["^deploy:ci"],
with
"dependsOn": [],
and this does result in only the correct packages being rebuilt, but the deploy order is willy-nilly. Ideally, I'd have this latter behavior while still enforcing backend always goes before web.

Generate i18n static HTML using Parcel bundler

I'm using Parceljs to bundle html and js. It works really well with less configuration.
Now, I'm facing i18n issue.
Google recommends using different URLs for each language version of a page.
https://support.google.com/webmasters/answer/182192
So, I want to generate language specific static html from one template like below.
.
├── dist
│ ├── ja
│ │ └── index.html
│ ├── app.c328ef1a.js
│ └── index.html
├── i18n
│ ├── default.json
│ └── ja.json
└── source
├── app.js
└── index.html
source/index.html
<html>
<body>
<h1>__TITLE__</h1>
<script src="/app.js"></script>
</body>
</html>
i18n/default.json
{
"__TITLE__": "Hello world!"
}
i18n/ja.json
{
"__TITLE__": "こんにちは 世界!"
}
Is there a way to deal with this issue using parceljs?
Or, should I write a code for prebuild?
Thank you.
Self answer:
I found a great answer here.
It mentions node-static-i18n package that generates i18n static HTML.
This tool isn't a plugin of parceljs, but it seems to be able to generate expected results.
Welcome yet another answer.

Copy NPM module/library to distribution folder using Gulp

Most web applications these days include various prebuilt libraries e.g. Backbone.js.
I want, when I compile my web application with Gulp, to output a single compressed JavaScript file of the library/module I installed using NPM e.g. backbone-min.js.
For example, when you install Backbone.js from NPM the following is installed into the node_modules folder:
.
├── backbone
│   ├── LICENSE
│   ├── README.md
│   ├── backbone-min.js
│   ├── backbone-min.map
│   ├── backbone.js
│   └── package.json
I want to be able to run gulp compile and get the following result in my web application distribution folder:
.
├── index.html
├── scripts
│   ├── backbone-min.js // this is the file I want to copy or generate
│   ├── main.min.js
The way I see it Gulp either needs to either:
compile and minify the library/module and write it to a file called backbone-min.js to the scripts folder, or
copy the backbone-min.js in the backbone module folder to the scripts folder.
What is the best way of doing this?
Short Answer
gulp-useref concatenates all the file references in your main .html file encapsulated by <!--build:js /lib.js--> for javascript files and <!--build:css /lib.css--> followed by <!--endbuild-->
The result will be:
index.html
├── scripts
│ ├── backbone-min.js // this is the file I want to copy or generate
│ ├── main.min.js
as you and every good developer wants it to be.
Long Answer
My recommendation would be to use Bower as your app dependencies manager and npm as your development dependencies manager.
Use gulp-wiredep to automatically inject dependencies as you install/uninstall them and that way you don't have to maintain library css and js files in your index.html.
Uset gulp-inject to automatically inject your own css and js files as your add/remove them. This will result in never ever having to maintain application dependencies manually.
With wiredep, inject and useref you never have to touch your dependencies again.
This is what my index header and end of body look like:
<!---------------------------- Bower Managed Styles ----------------------------->
<!--build:css css/lib.css-->
<!--bower:css-->
<link rel="stylesheet" href="../bower_components/..."
<!--endbower -->
<!--endbuild -->
<!---------------------------- Application Styles ------------------------------->
<!--build:css css/app.css-->
<!--inject:css-->
<link rel="stylesheet" href="content/css/bootstrap ..."
<!--endinject-->
<!--endbuild-->
<!--------------------------- Bower Managed Javascript ------------------------->
<!--build:js js/lib.js-->
<!--bower:js -->
<script src="../bower_components/ ..."> </script>
<!--endbower -->
<!--endbuild -->
<!-------------------------- Application Javascript --------------------------->
<!--build:js js/app.js-->
<!--inject:js-->
<script src="app/ ..."> </script>
<!--endinject-->
<!--inject:templates:js-->
<!--endinject-->
<!--endbuild-->
The comments are tags used by the tools I just mention in order for them to know where to insert the dependencies of interest.
My application entry is a single template reference. Needless to say I never visit index.html. I never have a reference to a file that does not exist. I never have a file that does not have a reference.

Categories

Resources