I'm using the verion 2.7 of Parcel for bundling my client side javascript. I have a index.ts where I group all my code. In some cases I have to use dynamic import statements:
example:
const { Menu } = await import('./Menu');
The issue that I can't solve: after each update on Menu.ts, Parcel creates a newly hashed Menu.[hash].js file instead of updating it.
npm run watch:js:
"watch:js": "parcel watch --no-hmr ./public/ts/index.ts --dist-dir ./public/js --public-url ./"
public folder structure:
.
└── public/
├── [...]
├── js/
│ ├── index.js
│ ├── index.js.map
│ ├── Menu.[hash-1].ts **! that's an issue !**
│ └── Menu.[hash-2].ts **! that's an issue !**
└── ts/
├── [...]
├── index.ts
└── Menu.ts
The project is located at https://github.com/eric-g-97477/blog-ember-d3 which is a fork of this project.
The output of npm list is:
$ npm list
blog-ember-d3#0.0.0
├── #ember/jquery#0.6.0
├── #ember/optional-features#0.7.0
├── broccoli-asset-rev#3.0.0
├── d3-graphviz#4.1.1
├── d3-selection#3.0.0
├── d3#5.9.2
├── ember-ajax#5.0.0
├── ember-cli-app-version#3.2.0
├── ember-cli-babel#7.7.3
├── ember-cli-dependency-checker#3.1.0
├── ember-cli-eslint#5.1.0
├── ember-cli-htmlbars-inline-precompile#2.1.0
├── ember-cli-htmlbars#3.0.1
├── ember-cli-inject-live-reload#1.10.2
├── ember-cli-sri#2.1.1
├── ember-cli-template-lint#1.0.0-beta.3
├── ember-cli-uglify#2.1.0
├── ember-cli#3.10.1
├── ember-d3#0.5.1
├── ember-data#3.10.0
├── ember-export-application-global#2.0.0
├── ember-load-initializers#2.0.0
├── ember-maybe-import-regenerator#0.1.6
├── ember-qunit#4.4.1
├── ember-resolver#5.1.3
├── ember-source#3.10.0
├── ember-welcome-page#4.0.0
├── eslint-plugin-ember#6.4.1
├── eslint-plugin-node#9.0.1
├── loader.js#4.7.0
└── qunit-dom#0.8.5
I am trying to import by doing:
import { graphviz } from "d3-graphviz";
and that generates the error:
Uncaught Error: Could not find module `d3-graphviz` imported from `blog-ember-d3/libs/donut-chart`
I am sure this is something silly, but I am not sure what has gone wrong.
My goal was to start with a d3 based project that worked and determine how to get d3-graphviz working within it.
If you add ember-auto-import, you should be able to import from d3-graphviz. ember-auto-import sets up webpack and allows things to "just work" from npm, and is standard in all ember apps since ember-cli 3.16
Also, if you're starting a new app, you may want to update ember-cli so you get the latest blueprint.
npm install -g ember-cli#latest
I’m using redux and I’m not sure about how to organize my components, I think the best is to keep them in folders with the name of the main component as the name of the folder and all inner components inside:
components
Common/ things like links, header titles, etc
Form/ buttons, inputs, etc
Player/ all small components forming the player
index.js this one is the top layout component
playBtn.js
artistName.js
songName.js
Episode/ another component
Then, in the containers folder, I’ve one container per page, that are the only ones I'm actually connecting to Redux:
containers/
HomePageApp.js
EpisodePageApp.js
...
and then the actions are one per each top component, instead of one per page, so in the page container that I connect to Redux I pass all the actions of the components used in that page. For example:
actions/
Player.js
Episode.js
...
Am I doing this right? I haven't found much information about it googling, and the ones I've found I think they are limited to small projects.
Thanks!
In the official examples we have several top-level directories:
components for “dumb” React components unaware of Redux;
containers for “smart” React components connected to Redux;
actions for all action creators, where file name corresponds to part of the app;
reducers for all reducers, where file name corresponds to state key;
store for store initialization.
This works well for small and mid-level size apps.
When you want to go more modular and group related functionality together, Ducks or other ways of grouping functionality by domain is a nice alternative way of structuring your Redux modules.
Ultimately choose whatever structure works best for you. There is no way Redux authors can know what’s convenient for you better than you do.
This is more a question about best practices / code style, and there is no clear answer. However, a very neat style was proposed in the React redux boilerplate project. It's very similar to what you currently have.
./react-redux-universal-hot-example
├── bin
├── src
│ ├── components // eg. import { InfoBar } from '../components'
│ │ ├── CounterButton
│ │ ├── GithubButton
│ │ ├── InfoBar
│ │ ├── MiniInfoBar
│ │ ├── SurveyForm
│ │ ├── WidgetForm
│ │ └── __tests__
│ ├── containers // more descriptive, used in official docs/examples...
│ │ ├── About
│ │ ├── App
│ │ ├── Home
│ │ ├── Login
│ │ ├── LoginSuccess
│ │ ├── NotFound
│ │ ├── RequireLogin
│ │ ├── Survey
│ │ ├── Widgets
│ │ └── __tests__
│ │ └── routes.js // routes defined in root
│ ├── redux
│ │ ├── init.js
│ │ ├── middleware
│ │ │ └── clientMiddleware.js // etc
│ │ └── modules // (action/creator/reducer/selector bundles)
│ │ ├── auth.js
│ │ ├── counter.js
│ │ ├── reducer.js
│ │ ├── info.js
│ │ └── widgets.js
│ ├── server
│ │ ├── middleware
│ │ └── actions // proxy to separate REST api...
│ └── utils
│ │ ├── validationUtility.js // utility only (component-level definitions inside respective dir)
│ └── createDevToolsWindow.js // etc
├── static
│ ├── dist
│ └── images
└── webpack
I prefer keeping smart and dumb components in the same file, but use default export for smart component and export for presentation/dumb components. This way you can reduce file noise in your directory structure. Also group your components by "View" i.e. (Administration => [admin.js, adminFoo.js, adminBar.js], Inventory => [inventory.js, inventoryFoo.js, inventoryBar.js], etc).
I have no strong opinion about the component directories, but I like putting the actions, constants and reducers together:
state/
actions/
index.js
...
constants.js
reducers.js
I alias state with with webpack so in the container components I can import {someActionCreator} from 'state/actions';.
This way, all the stateful code in the app resides in a single place.
Note that reducers.js could be split into multiple files simply by making a reducers/ directory like actions/ and you wouldn't have to change any import statements.
In Redux you have one entry point for your actions (actions/ folder) and an entry point for the reducers (reducers/ folder).
If you go with domain-based code structure you simplify domain/feature implementation and maintenance... on the other hand you are complicating component dependencies and app state/logic maintenance.
Where are you gonna put reusable components? inside feature/domain folder? so if you need a reusable component from other feature/domain you need to create a dependency between domains? mmh not so good for large app!
When you have to combine reducers, domain-code-structure takes away what it gave you previously.
You are only creating single redux modules for each domain/feature.
domain-code-structure should be good in some/most cases, but this is not Redux.
I have a boilerplate with react, redux folder structure and it's being used for many company projects. You can check it out here: https://github.com/nlt2390/le-react-redux-duck
I used Express generator to create node application. Directory structure looks like the following:
.
├── app.js
├── bin
│ └── www
├── package.json
├── public
│ ├── images
│ ├── javascripts
│ └── stylesheets
│ └── style.css
├── node_modules
│ └── jquery
│ └── dist
| |___jquery.min.js
├── routes
│ ├── index.js
│ └── users.js
└── views
├── error.jade
├── index.jade
└── layout.jade
In my index.jade file i try to reuse jquery.min.js from node_modules, instead use url to web source:
doctype html
html
head
link(rel='stylesheet', href= '/stylesheets/style_monit.css')
body
#container
.row
.col-sm-4(style='background-color:lavender;') .col-sm-4
.col-sm-4(style='background-color:lavenderblush;') .col-sm-4
.col-sm-4(style='background-color:lavender;') .col-sm-4
.col-md-4
textarea#inData.form-control(style='background:#222; color:#00ff00;', rows='8')
script(type='text/javascript' src='../node_modules/jquery/dist/jquery.min.js')
css file loads great, but in Chrome console i have error that
GET http://localhost:3000/node_modules/jquery/dist/jquery.min.js
NOT FOUND
I believe the problem is that the node_modules directory is private and shouldn't be exposed to the client. Only static files in the public directory can be served. See this Stack Overflow answer for more information.
I'm working to cleanly structure my AngularJS app according to best practices, which includes separating the controllers and app into different script files.
Quick question: where should I put my factories and services? I am asking in the context of having factories & services that will be accessed outside of the scope of a single controller as well as having some that are within the scope of a single controller.
Update: the immediate answer below is no longer correct. Please see the latest addendum (written March 1, 2015) to this answer.
Got it! According to Brian Ford's article on Building Huuuuuuuge Angular Apps, the best practice appears to be to connect services and factories to the app in a separate file, like so:
root-app-folder
├── index.html
├── scripts
│ ├── controllers
│ │ └── main.js
│ │ └── ...
│ ├── directives
│ │ └── myDirective.js
│ │ └── ...
│ ├── filters
│ │ └── myFilter.js
│ │ └── ...
│ ├── services
│ │ └── myService.js
│ │ └── ...
│ ├── vendor
│ │ ├── angular.js
│ │ ├── angular.min.js
│ │ ├── es5-shim.min.js
│ │ └── json3.min.js
│ └── app.js
├── styles
│ └── ...
└── views
├── main.html
└── ...
(PSST! In case you're wondering, Brian Ford is part of the AngularJS team, so his answer seems pretty legit.)
Addition (April 24, 2013)
This just in: Yeoman is a fantastic tool for generating apps with the proper directory structure for big, functional Angular apps. It even has Grunt & Bower packed in!
Addendum (March 1, 2015)
According to a comment via PaoloCargnin, Google actually recommends a different structure, as detailed by this document. The structure should look like this:
sampleapp/
app.css
app.js //top-level configuration, route def’ns for the app
app-controller.js
app-controller_test.js
components/
adminlogin/
adminlogin.css //styles only used by this component
adminlogin.js //optional file for module definition
adminlogin-directive.js
adminlogin-directive_test.js
private-export-filter/
private-export-filter.js
private-export-filter_test.js
userlogin/
somefilter.js
somefilter_test.js
userlogin.js
userlogin.css
userlogin.html
userlogin-directive.js
userlogin-directive_test.js
userlogin-service.js
userlogin-service_test.js
index.html
subsection1/
subsection1.js
subsection1-controller.js
subsection1-controller_test.js
subsection1_test.js
subsection1-1/
subsection1-1.css
subsection1-1.html
subsection1-1.js
subsection1-1-controller.js
subsection1-1-controller_test.js
subsection1-2/
subsection2/
subsection2.css
subsection2.html
subsection2.js
subsection2-controller.js
subsection2-controller_test.js
subsection3/
subsection3-1/
etc...