I would like to ask for your opinion on the file structure and file names.
I am a beginning React programmer and I am interested in the opinion of experienced developers.
Is there anything you don't really like about the structure and the names themselves?
└── src
├── components
│ ├── layout
│ │ └── ThemeSwitcher.tsx
│ ├── movieDetail
│ │ ├── BackToHomepage.tsx
│ │ ├── FavoriteMovieButton.tsx
│ │ ├── MovieLoader.tsx
│ │ └── MovieTable.tsx
│ └── movieList
│ │ ├── MoviesList.tsx
│ │ ├── PaginationBar.tsx
│ │ └── SearchBar.tsx
├── img
│ ├── favorite-active.png
│ └── favorite-inactive.png
├── layout
│ ├── Header.tsx
│ └── Main.tsx
├── pages
│ ├── Detail.tsx
│ ├── Favorites.tsx
│ └── Homepage.tsx
├── redux
│ ├── movieDetail
│ │ ├── movieDetailSaga.tsx
│ │ ├── movieDetailSlice.tsx
│ │ └── movieDetailTypes.tsx
│ └── movieList
│ │ ├── moviesListSaga.tsx
│ │ ├── moviesListSlice.tsx
│ │ └── moviesListTypes.tsx
│ ├── rootSaga.tsx
│ └── store.tsx
├── styles
│ ├── abstracts
│ │ ├── mixin.scss
│ │ └── variables.scss
│ ├── base
│ │ ├── reset.scss
│ │ └── typography.scss
│ ├── components
│ │ ├── layout
│ │ │ └── ThemeSwitcher.scss
│ │ ├── movieDetail
│ │ │ ├── BackToHomepage.scss
│ │ │ ├── FavoriteMovieButton.scss
│ │ │ ├── MovieLoader.scss
│ │ │ └── MovieTable.scss
│ │ └── movieList
│ │ │ ├── MoviesList.scss
│ │ │ ├── PaginationBar.scss
│ │ │ └── SearchBar.scss
│ ├── pages
│ │ ├── Detail.scss
│ │ ├── Favorites.scss
│ │ └── Homepage.scss
│ └── main.scss
├── .d.ts
├── App.tsx
└── index.tsx
The following technologies were used in this particular project:
React create app
Typescript
Redux Toolkit
Redux Saga
Sass
Thank you for every suggestion.
https://reactjs.org/docs/faq-structure.html
"If you’re just starting a project, don’t spend more than five minutes on choosing a file structure. Pick any of the above approaches (or come up with your own) and start writing code! You’ll likely want to rethink it anyway after you’ve written some real code."
Your structure is fine. Like it's already said, do not overthink it.
Despite that, as you asked, I personally like to put components related to same feature together as you did.
Related
I am trying to create a web React app that has multiple pages. I was able to configure babel so that it watches a single directory and output the vanilla Javascript files one directory above. The problem is that I have multiple folders with React files, and I do not want to manually have a watch command for each directory. I was wondering if I was able to do this with one command that watches all js/react/ directories and outputs to the respective js/ directories.
//node_modules have been excluded for brevity
.
├── app.js
├── environment.js
├── package-lock.json
├── package.json
├── public
│ ├── colab
│ │ ├── create
│ │ │ ├── index.html
│ │ │ ├── main.js
│ │ │ ├── project.js
│ │ │ └── style.css
│ │ ├── home
│ │ │ ├── index.html
│ │ │ ├── js
│ │ │ │ └── react
│ │ │ │ ├── main.js
│ │ │ │ └── project.js
│ │ │ ├── style.css
│ │ │ └── test.json
│ │ └── navbar
│ └── homepage
│ ├── css
│ │ └── style.css
│ ├── images
│ │ ├── bixby.png
│ │ ├── fortniteskill.png
│ │ ├── turtle.png
│ │ └── turtle2.jpg
│ ├── index.html
│ └── js
│ └── react
└── main.js
└── routers
├── alexa.js
├── api.js
├── colab.js
└── home.js
npx babel --watch . --out-dir js/ --presets react-app/prod
I've followed these steps but I still can't create a react-native app
for MacOS
Install Homebrew
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Install Node
brew install node
Install watchman
brew install watchman
Finally install React Native CLI
npm install -g react-native-cli
/usr/local/Cellar/node/11.7.0/lib
└─┬ react-native-cli#2.0.1
├─┬ chalk#1.1.3
│ ├── ansi-styles#2.2.1
│ ├── escape-string-regexp#1.0.5
│ ├─┬ has-ansi#2.0.0
│ │ └── ansi-regex#2.1.1
│ ├─┬ strip-ansi#3.0.1
│ │ └── ansi-regex#2.1.1 deduped
│ └── supports-color#2.0.0
├── minimist#1.2.0
├─┬ prompt#0.2.14
│ ├── pkginfo#0.4.1
│ ├─┬ read#1.0.7
│ │ └── mute-stream#0.0.8
│ ├── revalidator#0.1.8
│ ├─┬ utile#0.2.1
│ │ ├── async#0.2.10
│ │ ├── deep-equal#1.0.1
│ │ ├── i#0.3.6
│ │ ├─┬ mkdirp#0.5.1
│ │ │ └── minimist#0.0.8
│ │ ├── ncp#0.4.2
│ │ └─┬ rimraf#2.6.3
│ │ └─┬ glob#7.1.3
│ │ ├── fs.realpath#1.0.0
│ │ ├─┬ inflight#1.0.6
│ │ │ ├── once#1.4.0 deduped
│ │ │ └── wrappy#1.0.2
│ │ ├── inherits#2.0.3
│ │ ├─┬ minimatch#3.0.4
│ │ │ └─┬ brace-expansion#1.1.11
│ │ │ ├── balanced-match#1.0.0
│ │ │ └── concat-map#0.0.1
│ │ ├─┬ once#1.4.0
│ │ │ └── wrappy#1.0.2 deduped
│ │ └── path-is-absolute#1.0.1
│ └─┬ winston#0.8.3
│ ├── async#0.2.10 deduped
│ ├── colors#0.6.2
│ ├── cycle#1.0.3
│ ├── eyes#0.1.8
│ ├── isstream#0.1.2
│ ├── pkginfo#0.3.1
│ └── stack-trace#0.0.10
└── semver#5.6.0
Use are using
react-native init
to create the project, right?
Otherwise, make sure it's in your PATH. See the following:
-bash: react-native: command not found
I am trying to adopt the new .component released in angular 1.5. Although I am having a tough time understanding where modules fit in now.
Before I used to separate my components into angular modules, what relationship does this have now that components are here ?
Just create one angular module and add all components under this, or continue to use angular modules as well as components ?
The documentation doesn't seem to go into this. If I am still using modules then what is the use of components, or if I am using components what is the use of more than 1 module ?
I'm in the same boat here...
Here is what I found. Hope this helps us all
From Angular Docs:
1.Module: You can think of a module as a container for the different parts of your app – controllers, services, filters, directives, etc.
Modules Recomended Setup
"... we recommend that you break your application to multiple modules like this:
A module for each feature
A module for each reusable component (especially directives and filters, Please see below component definition; special kind of directive)
And an application level module
which depends on the above modules and contains any initialization
code.
2.Component:In Angular a Component is a special kind of directive that uses a simpler configuration which is suitable for a component-based application structure.
Advantages of Components:
simpler configuration than plain directives
promote sane defaults and best practices
optimized for component-based architecture
writing component directives will make it easier to upgrade to Angular 2
When not to use Components:
for directives that need to perform actions in compile and pre-link functions, because they aren't available
when you need advanced directive definition options like priority, terminal, multi-element
when you want a directive that is triggered by an attribute or CSS class, rather than an element
So trying to make sense of all this its seems like you need a module to organize or as a top "container" if you will and then add component/subcomponent as required.
angular.module('app',[])
.component('component')
.component('common')
It all comes down to componetize the app:
This image is from angular 2 patterns in angular 1 (highly recommended)
Boottom line: Angular 1's doc is not that clear on the subject but we can see it as a way of organizing modules/components
Modules are always the containers to which
We add components and subcomponents depending on the structure
ToodMottos recomendation on File Structure
"...We should ideally have three high-level modules: root, component and common..."
Here we can see how modules become components and subcomponents
├── app/
│ ├── components/
│ │ ├── calendar/
│ │ │ ├── calendar.module.js
│ │ │ ├── calendar.component.js
│ │ │ ├── calendar.service.js
│ │ │ ├── calendar.spec.js
│ │ │ ├── calendar.html
│ │ │ ├── calendar.scss
│ │ │ └── calendar-grid/
│ │ │ ├── calendar-grid.module.js
│ │ │ ├── calendar-grid.component.js
│ │ │ ├── calendar-grid.directive.js
│ │ │ ├── calendar-grid.filter.js
│ │ │ ├── calendar-grid.spec.js
│ │ │ ├── calendar-grid.html
│ │ │ └── calendar-grid.scss
│ │ ├── events/
│ │ │ ├── events.module.js
│ │ │ ├── events.component.js
│ │ │ ├── events.directive.js
│ │ │ ├── events.service.js
│ │ │ ├── events.spec.js
│ │ │ ├── events.html
│ │ │ ├── events.scss
│ │ │ └── events-signup/
│ │ │ ├── events-signup.module.js
│ │ │ ├── events-signup.component.js
│ │ │ ├── events-signup.service.js
│ │ │ ├── events-signup.spec.js
│ │ │ ├── events-signup.html
│ │ │ └── events-signup.scss
│ │ └── components.module.js
│ ├── common/
│ │ ├── nav/
│ │ │ ├── nav.module.js
│ │ │ ├── nav.component.js
│ │ │ ├── nav.service.js
│ │ │ ├── nav.spec.js
│ │ │ ├── nav.html
│ │ │ └── nav.scss
│ │ ├── footer/
│ │ │ ├── footer.module.js
│ │ │ ├── footer.component.js
│ │ │ ├── footer.service.js
│ │ │ ├── footer.spec.js
│ │ │ ├── footer.html
│ │ │ └── footer.scss
│ │ └── common.module.js
│ ├── app.module.js
│ ├── app.component.js
│ └── app.scss
└── index.html
ToodMottos style Guide: Modular Achitecture (I must Read)
Here is more info on angular Module
Components in Angular 1.5 are special kind of directives which are suitable for component based architecture. They are more like directives on steroids.
Before I used to separate my components into angular modules, what relationship does this have now that components are here ?
Now that the components are there you can separate related components into different modules.
Just create one angular module and add all components under this, or continue to use angular modules as well as components ?
You can use the same pattern you used before to separate out the controllers.
components in angular 1.5 help you create actual components that have their own view and bindings. They were created to allow angular 1.5 devs understand the pattern and migrate easily to Angular 2.0 later.
The folder structure of my Angular-Meteor-app looks like this:
.
├── client
│ ├── app
│ │ ├── auth
│ │ │ ├── login
│ │ │ │ ├── login.controller.js
│ │ │ │ ├── login.html
│ │ │ ├── register
│ │ │ │ ├── ...
│ │ │ ├── reset-password
│ │ │ │ ├── ...
│ │ │ ├── route.config.js
│ │ ├── lib
│ │ │ ├── app.module.js
│ │ │ ├── auth.module.js
│ │ ├── ...
│ ├── ...
├── ...
Please note that because of Meteor's load order I cannot put auth.module.js under the auth directory but have to place it under the lib directory. Otherwise Angular would complain that the auth module could not be injected when used in login.controller.js. (Files in subdirectories are loaded before files in parent directories, all files in lib are moved before everything else.)
What I would like is to move auth.module.js in the auth folder, so I have all files of my auth module in the right place:
.
├── client
│ ├── app
│ │ ├── auth
│ │ │ ├── login
│ │ │ │ ├── login.controller.js
│ │ │ │ ├── login.html
│ │ │ ├── register
│ │ │ │ ├── ...
│ │ │ ├── reset-password
│ │ │ │ ├── ...
│ │ │ ├── auth.module.js
│ │ │ ├── route.config.js
│ │ ├── lib
│ │ │ ├── app.module.js
│ │ ├── ...
│ ├── ...
├── ...
Any idea how to manage this?
I think you've got at least two options:
Make client/auth flat, so that the lexicographic ordering will load auth.module.js before login.controller.js.
│ │ ├── auth
│ │ │ ├── auth.module.js
│ │ │ ├── login.controller.js
│ │ │ ├── login.html
│ │ │ ├── ...
Or use yet another lib sub-directory
│ │ ├── auth
│ │ │ ├── lib
| │ │ │ ├── auth.module.js
│ │ │ ├── login
│ │ │ │ ├── login.controller.js
│ │ │ │ ├── login.html
│ │ │ ├── ...
Of course, one could argue that your code should not depend in the load order, i.e., you should only use the auth code once everything is loaded, e.g., in oMeteor.startup or onCreate of templates.
I have been working in Java/J2ee projects, in which I follow the Maven structure.
I want to develop [say a command line interpreter in linux {ubuntu}] in C.
I never develop projects in C. I want to know what project structure I should follow.
There is no one "standard" for C project in this aspect. Certainly if your project is small, then frequently everything will be placed in a single directory.
You can try to download some popular open-source C projects and take a look at their code.
On a lower level, code should be modular. Each module (which in C is usually manifested in a data structure with a set of functions to act upon it) has its own pair of .h and .c files, with the .h file being the public interface visible to the clients of the module, and the .c file being the private implementation.
As Eli Bendersky sayd, it strictly depends on how complex is your project.
The standard suggests to split as much as possible into libraries. The point is that you may want to reuse your libraries elsewhere. By example this is a project of mine:
├── AUTHORS
├── COPYING
├── ChangeLog
├── Makefile.am
├── NEWS
├── README
├── configure.ac
├── libs
│ ├── featsel
│ │ ├── Makefile.am
│ │ ├── commander.c
│ │ ├── featsel
│ │ │ ├── commander.h
│ │ │ ├── feattuple.h
│ │ │ └── types.h
│ │ ├── featsel.h
│ │ ├── feattuple.c
│ │ ├── headers
│ │ │ └── datatypes.h
│ │ └── tests
│ │ ├── Makefile.am
│ │ └── test00.c
│ ├── mbox
│ │ ├── Makefile.am
│ │ ├── README
│ │ ├── control.c
│ │ ├── error.c
│ │ ├── headers
│ │ │ ├── datatypes.h
│ │ │ ├── mail.h
│ │ │ ├── parse.h
│ │ │ ├── split.h
│ │ │ └── strings.h
│ │ ├── interface.c
│ │ ├── mail.c
│ │ ├── mbox
│ │ │ ├── descriptor.h
│ │ │ ├── error.h
│ │ │ ├── mail.h
│ │ │ └── types.h
│ │ ├── mbox.h
│ │ ├── parse.c
│ │ ├── split.c
│ │ └── strings.c
│ └── thread_queue
│ ├── Makefile.am
│ ├── thrdqueue.c
│ └── thrdqueue.h
├── reconf
└── src
├── Makefile.am
└── main.c
I personally prefer to put all libraries into a libs directory. Every library except trivial ones has its own private header directory and exports a public header by means of a directory having the same name of the library.
The source file of the program itself is placed in the src directory.
A suggestion:
/project
README
LICENCE
Makefile
# mabe configure.am Makefile.am etc.
# see http://en.wikipedia.org/wiki/GNU_build_system
/src
Makefile
a.h
a.c
b.h
b.c
/subunit
x.h
x.c
y.h
y.c
# each file.c has a header file.h but not necessarily
...
Look at Nginx on github and browse the project structure online.
Separate functionalities in modules: .c files with implementation details/definitions paired with .h files with declarations.
Try not to pollute namespaces by using static for functions and a common module prefix for external symbols.
Create libraries if you have functionalities that can be encapsulated and reused.
You can refer to the OpenSSL Project structure. It's a famous open source and has a good project structure.