I'm currently working on a small Angular2 project. In my case i have to reroute some of the requests (like "/faq", "/aboutus") back to my old backend server to get some server side rendered thymeleaf templates. Therefore i'm using the built in proxy to reroute to my backende server. Sadly for some weird reason it only servers the html files without any scripts and styles or images. (i used the angular-cli to create my project structure)
Thats why i wanted to add these static files into my angular2 folder but i can't find the correct place to make it available to my application.
Does anyone else know how to correctly place these file inside the project structure ?
Thanks in advance for any help
According to the current angular-cli readme (v1.0.1):
You use the assets array in angular-cli.json to list files or folders you want to copy as-is when building your project:
"assets": [
"assets",
"favicon.ico"
]
By default the assets folder is configured for this, so you can place your files into a structure like
├── src
. ├── assets
. . ├── file1.txt
. . ├── img
. │ └── image1.png
└── css
and serve them from url path /img/image1.png etc.
If you're not happy with the default option, add a folder name of your choice to angular-cli.json, i.e.
"assets": [
"static",
...
]
Create the ./src/static/ folder for your files and serve analogously to the default.
Related
There are SSR-related problems with several pages in Next.js project that results in errors on npm run build and prevent the project from being built:
pages/
foo/
bar/
[id].jsx
index.jsx
index.jsx
...
For example, bar:
export function getStaticProps() {
return someApiCallThatCurrentlyFails()
...
}
export default function Bar() {...}
As a quick fix, it may be convenient to just not build bar/*.* pages and make routes unavailable.
Can pages be ignored on Next.js build without physically changing or removing page component files in the project?
You can configure the pageExtensions in the next.config.js.
// next.config.js
module.exports = {
pageExtensions: ["page.js"],
}
After configuring this, the only pages with *.page.js will be considered in the below given directory structure.
pages/
├── user
│ └── setting
│ ├── index.js
├── _app.page.js
├── _document.page.js
├── list.page.js
└── theme.ts
Custom file ignores patterns that are not supported yet. You can visit the PR created here, and the solution given here. This is the most satisfactory solution so far.
#Mathilda Here from Nextjs docs: it's necessary for all pages including _app, _document, etc.
https://nextjs.org/docs/api-reference/next.config.js/custom-page-extensions
Changing these values affects all Next.js pages, including the following:
- middleware.js
- pages/_document.js
- pages/_app.js
- pages/api/
For example, if you reconfigure .ts page extensions to .page.ts, you would need to rename pages like _app.page.ts.
There are plenty of questions and tutorials on this topic, but none of them cover all use cases for a chrome extension, because most of them assume there's only one entry point.
Here are the requisites:
Multiple "single page applications":
1) popup.html for the extension pop up page
2) options.html for the options page
3) custom.html this is a custom .html file that the extension can refer to "locally"
Each of these files are entry points for React to manipulate the DOM, but they behave independently of each other.
Non React TypeScript files
They must not be bundled together with any other scripts, and gets compiled to its own JavaScript file, for example a background.ts that compiles to background.js (which is refered to in the manifest.json).
I assume this is doable with TypeScript, React and Webpack but I'm not sure how to approach that.
There is a custom CRA template that exactly fits your needs: complex-browserext-typescript.
Usage:
npx create-react-app my-app --template complex-browserext-typescript
By default it sets up 4 entry points associated with page-like extension components:
popup (src/index.tsx) - extension's popup page, replaces the
default index entry point.
options (src/options.tsx) - extension's options page.
background (src/background.ts) - background script.
content (src/content.ts) - content script.
However there is an option to exclude any of the above components except the popup from compilation as well as add extra HTML page(s).
Also see this article for usage example.
I found a solution but it was not using create-react-app and webpack. It looks like parcel supports multiple entry points out of the box without any configuration.
Assuming a directory structure like this:
├── chrome
│ └── background.ts
├── html
│ ├── custom.html
│ ├── options.html
│ └── popup.html
├── manifest.json
├── package.json
├── react
│ ├── custom.tsx
│ ├── options.tsx
│ └── popup.tsx
With Parcel.js you simply do:
parcel build html/*.html react/*.tsx chrome/*.ts
And it will handle the multiple entry points. I created a repository that contains a template for that approach, it contains a fully runnable example.
Here is the structure of my Hugo theme:
The site with config file is in exampleSite folder. After I run hugo --config ./exampleSite/config.toml command. A few files generated in public folder.
Some folders like about, images are missing.
But when I run hugo command in exampleSite folder. All files are generated.
When I add debug or verbose flags to the command, there is no error at all. What could be the reason?
A minimal Hugo site
To build a Hugo site, this is the minimum setup that you need:
.
├── config.toml
├── content
│ ├── about.md
│ └── first-post.md
├── layouts
config.toml is described in the configuration docs. You'll want at least a baseURL and a title added.
content/ - this is where the writing goes; Markdown documents here get translated into HTML pages. More details in the Content organisation chapter.
layouts/ - this is where the page templates go.
For more info on this, check the Hugo directory structure, part of the getting started guide.
At this point, running the hugo command, i.e. compiling your site, will output the result in the public directory by default. Without any HTML templates, you'll just get a sitemap and some RSS XML.
Cue Hugo themes
In your case, you want to use a ready-built theme, so you need an extra themes directory, in which you can have one directory for each theme you want to use, e.g. themes/my-hugo-theme. In your config.toml, you need to set theme = my-hugo-theme, which is the directory name.
Using a separate theme means that Hugo will use the theme's layouts (themes/my-hugo-theme/layouts/) to generate your site's documents (content/).
exampleSite/
As a convention, themes posted on Hugo's library have an exampleSite/ directory to show off all the available features. Those files are ignored when you use the theme in your own site.
What you could do is copy the stuff in exampleSite over to your own content directory, and run again. From there, you can just change the content and remove what's not used.
Hope this helps!
We have developed a React component library for internal use. The library uses webpack to bundle everything into a bundle.js. The library is exposed as an NPM module for use by our applications, which so far has been working great.
Recently we added a Grid component that has some very large external dependencies. Even though a few of our applications won't need this component from the library, we decided to include it in the final bundle. This can make a huge difference in bundle size, so I followed Webpack's code splitting guide to break out the Grid component using a dynamic import. For our applications that have this library installed as an NPM module, the component library bundle now looks like this in node_modules:
├── node_modules/
│ ├── [our component library]/
│ │ ├── Grid.js # Asynchronously loaded Grid component
│ │ ├── bundle.js # Main bundle
│ │ └── ... other files in component library bundle
When building the application (also with Webpack), the Grid component doesn't seem to be getting included as its own file in the final bundle. In fact, it doesn't get included at all:
├── dist/
│ ├── main.js # App bundle
│ ├── vendor.js # Vendor bundle created with CommonChunksPlugin
│ └── ... other files in application bundle but no Grid.js
When trying to load a page in the browser that is using the asynchronously loaded Grid component, Webpack returns the following error:
Error: Loading chunk 0 failed.
at HTMLScriptElement.onScriptComplete (bundle.js:757)
Essentially, this says the Grid component chunk can't be found. What am I doing wrong? Is it even possible to code split a React component library like this?
I used https://webpack.js.org/guides/code-splitting/#dynamic-imports both import() and require.ensure syntax for dynamic imports. Both worked well. Check this project of mine for good example https://github.com/croraf/myboiler.
This project also is an example: https://github.com/croraf/nutrients-calculator. But I complicated dynamic import part a bit. Check https://github.com/croraf/nutrients-calculator/blob/master/frontend/src/App.js and https://github.com/croraf/nutrients-calculator/blob/master/frontend/src/routes/util/DynamicRoute.js files.
We decided to take a different route with this. Instead of including the Grid component with the rest of the components we split if off into its own npm module. I still see a use case for dynamically importing react components in a library but we felt this was a better solution to our problem. With this solution, the only real downside is that the application will now need to add 2 npm modules instead of one if it needs to use the Grid component and our standard component library. Since our application does code splitting by route with webpack + dynamic imports, the Grid code only gets bundled into the route that needs it.
one possible reason is babel transpiled your code from import("..") to require. check transpiled file to confirm this.
if this is the case and you are using preset, you can add this to disable this behavior:
"#babel/preset-env",
{
**"modules": false,**
"targets": {
"esmodules": true
}
}
],
I've read a lot of articles and questions about site folder structure (develop & deploy) and still have missunderstood about questions below.
I marked my current folder structure:
Orange- looks like lib or vendor folder, where i'd like to store independent components;
Blue- folder contains my own, relative to current project (application) files;
Green- ready to deploy folder, that contains minified & concated files, which used to be included in index.html.
There are a few questions i'd like to find an answer:
Is it correct, that the best practise is deploying to web server only dist folder?
Should i concat my bower_components & app javascript files into single app.min.js file? Should i mess independent components with application files and ober ordering?
Should i deploy views folder with templates as is into dist/views folder?
Is it correct to mess all images (css images, app images, plugin images) into single dist/images folder?
Is it correct to store directive templates in views folder?
There is not relative to AngularJS client/app/js/common/helpers.js file,- i can't figure out where is the most obvious place for that (it could be prototypes, custom functions or objects)
I will be glad for any help, ty.
Here is my setup that I'm using for a few different enterprise Angular SPA's using bower and gulp.
My app folder is like yours, but I also keep my index.html template there. Gulp uses it and injects the CSS/JS files that I want (.min files when I do a release). I have it put an index.html in the root of the website (for debug).
I separate my bower and app scripts into lib.min.js / app.min.js. Instead of minifying the bower stuff myself, I just concat all of the .min files. I minify and concat my app scripts.
Instead of your dist folder, I stage everything for release in obj/client (VS automatically creates the obj folder for temp files). I don't include this in the solution (I don't want it in source control).
I don't have a views folder for release. Using gulp everything is stored in the Angular template cache (it's gets put in there with app.min.js). You'll see these also get a random string as a suffix (that's for cache busting).
In the end, my deployment consists only of index.html, app (dist in your case) and bin folders, and web.config. I exclude the gulpfile, bower.json, etc.
Here is my directory structure for an angular site I'm building called Simple Team that is bound together using Browserify.
This is my document root where my framework starts and serves public files. All my JS and HTML is bound together into app.min.js.
This is how I build my directives as modules with the views require()'d in.
"use strict"
require('moment')
require('angular-ui-router')
require('angular-ui-sortable')
require('angular-gravatar')
require('angular-elastic')
require('angular-local-storage')
require('angular-moment')
require('./routes.js')
require('./modules/focusMe')
require('./modules/selectize')
require('./modules/tagData')
require('./modules/www')
require('./modules/uiSrefActiveIf')
angular
.module('simple.team', [
'ngFileUpload',
'ui.router',
'ui.sortable',
'ui.gravatar',
'ui.bootstrap',
'selectize',
'angularMoment',
'angular-loading-bar',
'ng-showdown',
'LocalStorageModule',
'monospaced.elastic',
'textAngular',
'simple.team.uiSrefActiveIf',
'simple.team.routes',
'simple.team.focusMe',
'simple.team.ngBindHtmlUnsafe',
'simple.team.bytes',
'simple.team.strings',
'simple.team.auth',
'simple.team.tagData',
'simple.team.userData',
'simple.team.www'
])
.config(function($urlRouterProvider, cfpLoadingBarProvider) {
$urlRouterProvider.otherwise('/projects')
cfpLoadingBarProvider.includeSpinner = false
})
.controller('AppCtrl', function($state, $http, $rootScope) {
// Controller code
})
Routes and controllers
angular
.module('simple.team.routes', [])
.config(function($stateProvider) {
$stateProvider
.state('projects', {
url: '/projects',
template: require('./layouts/projects.html'),
controller: ProjectsCtrl,
controllerAs: 'ctrl'
})
.state('projects.card', {
url: '/card/?cardId',
template: require('./layouts/card.html'),
controller: require('./controllers/card.ctrl.js'),
controllerAs: 'ctrl'
})
Sorry I not get enough time to do some research and write all answers
May be I edit it later..
Questions 1:
Is it correct, that the best practise is deploying to web server only dist folder?
Answer, Yes
Here is an example directory structure in which source code (src) is separated from temporary precompiled assets (.tmp), which are separated from the final distribution folder (dist). The src folder contains higher level languages such as jade, typescript and scss; the .tmp contains compiled js, css and html files; while the dist folder contains only concatenated and minified files optimized to be served in production.
.
├── .tmp
│ ├── app.css
│ ├── app.js
│ ├── header.html
│ └── index.html
├── bower_components
│ └── angular
├── dist
│ ├── app.min.css
│ ├── app.min.js
│ └── index.html
└── src
├── app.scss
├── app.ts
├── components
├── header.jade
├── index.html
└── shared
Here is a link that you can find more information
Gulp Best Practices You Can Use Today to Radically Improve Your Development Experience
Should use folder per type: http://www.johnpapa.net/angular-app-structuring-guidelines/
Directive script and view should be in same folder.
Only deploy the dist folder.
Images can all be in dist/assets/images (or dist/components/images). In my projects, I have all directives, services, and images under dist/components (dist/components/services, dist/components/partials [for directives]). And in the root, I have a folder for each router/section (ie. dist/login, dist/home), which includes all relevant script, view, tests.
If a directive or service is used in multiple router/sections, I put it in dist/components/.... If it is only used in the one section, I put it right under the folder for that route instead.