1 | # Skypager Project / Portfolio
|
2 |
|
3 | **IDEA**: Take full advantage of naming conventions and patterns
|
4 |
|
5 | You will notice the following about our file structure:
|
6 |
|
7 | - ./Helpers/models
|
8 | - ./Helpers/models/Component.js
|
9 | - ./Helpers/models/DataSource.js
|
10 | - ./Helpers/models/Project.js
|
11 |
|
12 | From the file structure alone we can deduce that among these files, there are several types of files which
|
13 | all seem to be a type of `Helpers` called `commands`. If we look more closely at them, we can see they all export
|
14 | a javascript module that has a similar structure:
|
15 |
|
16 | ```javascript
|
17 | export const execute = (options = {}, context = global) => {
|
18 | const { project } = context
|
19 | }
|
20 |
|
21 | export const command = (commander) => commander
|
22 | .program('myCommand').
|
23 | .usage('usage description')
|
24 | ```
|
25 |
|
26 | What this allows us to do is write a common and abstract interface on top of
|
27 | ever expanding collection of different javascript modules that amongst ourselves, we refer to as commands.
|
28 |
|
29 | **Note:** The technology this project is based on doesn't need to dictate very much about what
|
30 | exactly a command does, or what modules and third party libraries commands depend on.
|
31 |
|
32 | It doesn't provide much outside of ways for leveraging the ability to make certain assumptions about our code
|
33 | based on what names we give to the things inside of our project and where we store them.
|
34 |
|
35 | People who work with Ruby on Rails are going to be very familiar with this concept, and i only recently
|
36 | learned of the name `Inversion of Control`, which is how people describe this pattern of building larger applications
|
37 | and having a framework look for certain types of functionality in certain folders in the project.
|
38 |
|
39 | As helpful as this pattern cane be, applying these ideas in Javascript is still very labor intensive. For people who do not work with
|
40 | monolithic frameworks, enjoying the benefits of this practice is still mostly personal, or mostly manual and
|
41 | dependent on people learning the system.
|
42 |
|
43 | ## Products
|
44 |
|
45 | This section describes the different folders of the project which contain source code and assets for products
|
46 | produced for the purposes of supporting interaction with this portfolio, such as in the
|
47 | form of an API, Website, Desktop App, etc.
|
48 |
|
49 | ### App
|
50 | > an Electron App that uses React.js and the React Semantic-UI component kit
|
51 |
|
52 | ### Documentation
|
53 | > A Website with information about the design, concepts, and other details for this project
|
54 |
|
55 | ### Server
|
56 | > A Realtime API for interacting with the portfolio especially in development and test, but also in production.
|
57 |
|
58 | ## Collections
|
59 |
|
60 | This section describes nested subfolders which are deliberately named according to specific categories
|
61 | which can communicate essential facts for how the projects are used. |
\ | No newline at end of file |