Skip to content
This repository has been archived by the owner on Sep 15, 2018. It is now read-only.

What app structure are we going to follow? #8

Open
sinan-aumarah opened this issue Jul 19, 2017 · 7 comments
Open

What app structure are we going to follow? #8

sinan-aumarah opened this issue Jul 19, 2017 · 7 comments
Labels

Comments

@sinan-aumarah
Copy link
Contributor

Hi guys,

Based on our previous discussion; it seems like we need to keep this app as simple, as light and as small as possible. So does that mean we don't need too many components and nested app structure?
Should we just put all the components we have in like {root}/component/* and not have too many small atomic components?

Can you please review the current project structure and see if it makes sense to you? I think the way we handled views/watch pages is not clear enough

@raytung
Copy link
Contributor

raytung commented Jul 19, 2017

I prefer to have reusable components under the components/ directory, and pages live directly under src/.

Something like:

src
├── components/
│   └── GenericList/
├── ContactPage/
│   └── ContactList/
└── HomePage/

@alex-mitchem
Copy link
Contributor

I like Ray's suggestion. The main requirement is that it shows the separation of concerns within our app.

@watsonarw
Copy link
Contributor

I would like to ensure that we have a clear separation between "the framework", things that the students shouldn't need to touch, and "the app", things that the students change/add.

Also, the pages as root starts to get a bit messy if we start adding other concerns e.g. models, constants, services (hopefully we don't need services), so maybe having pages under a common directory isn't too bad

Which would make me think we have a structure similar to:

src
├── app/
│   ├── components/
│   │   └── GenericList/
│   └── pages/
│       ├── ClockPage/
│       │   └── AlarmNotification/
│       ├── ContactPage/
│       │   └── ContactList/
│       └── HomePage/
└── framework/
    ├── Router/
    ├── components/
    │   └── BaseNotification/
    ├── index.js
    ├── models/
    │   └── Clock/
    └── pages/
        ├── BasePage/
        └── MenuPage/

In this structure src/framework/index.js would be the interface which exports anything from the framework that the students would need to use (e.g. BasePage, MenuPage, Clock). In future we could extract it out like we've done with the current app, to actually prevent them from making changes in "framework".

@sinan-aumarah
Copy link
Contributor Author

sinan-aumarah commented Jul 20, 2017

Thanks for the replies guys, I'll do a restructure today based on your suggestions and maybe then we can discuss it. I'm currently leaning towards a structure similar to Andrew has suggested

@aaron-m-edwards
Copy link
Contributor

As an alternative to Andrews suggestion, do we need the framework code in the same repository? Could we setup a "framework repo" that contains all the code for the actual framework and allow the students to pull it in via npm?

This would probably require us writing a bit of documentation so maybe not for the first cut

@watsonarw
Copy link
Contributor

Ultimately, I would expect the framework to live outside the student repos as it does with the current watch. But for ease of building it, I'd prefer to keep them in the same repo for now, and extract it out later.

If we structure it with app/framework and an index.js file that exposes the parts of the framework which the students can import, then extracting the framework to its own repository later becomes much easier.

@sinan-aumarah
Copy link
Contributor Author

Agreed. The framework code can be pulled out at any point but for now we can just keep it there since we're still in dev stage.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants