Project Walkthrough

Starting Phoenix Framework for Rails Developers - Lesson 4

You are not signed in! It would mean a lot to me if you signed up through Github
- I would like to see who you are and I might occationally reach out to you with information aboout updates and questions.

Just like when you start a new project with Ruby on Rails, there is a pre decided file structure setup. The big benefit with this is of course that you don’t need to take up mind space with tiny decisions and open up to focus on more complex problems.

Also, other developers will have an easier time to navigate around in your problem. And the same goes for you, when you look in another person’s code.

I will go through the folder structure and highlight the important parts that you need to know when getting started.

_build - is a folder that you should never need to touch. Its where the compiled application is stored. So I will not go deeper into that in this course.

assets - is the folder where images, stylesheets and javascript lives. By default it uses webpack for bundling. One thing to keep in mind is that when you need to run javascript commands, like npm or yarn I need to make sure I run them from inside the assets folder.

config - this folder contains the config files. The entry point is the config.exs and that file contains some common configs for all environments. That file in turn reads in the config file that corresponds to the environment you are running. So, dev, test or prod.

deps - in this folder, all the libraries that has been pulled in…..

lib - this is the most important folder. Here is where the actual application lives. If I open the folder I can see two main folders. listz and listz_web. The idea is that the business logic should live in the listz folder and only the outward facing part should live in the listz_web.

Phoenix has a concept of splitting business logic into different context. A context is just a normal module that acts as a interface to the rest of the application. In this course, we started with generating the Posts context.

In the Posts context I have all the functions required for showing, creating, updating and deleting posts. As the application grows, I might need other functions here as well or might even extract some of these functions into their own files inside the posts folder.

The web interface lives inside listz_web folder. Just like in Rails, there is a router file where I need to set up to which controller a specific request should land.

I will go into more on how the router works, but here as you can see I have setup the root route and the resource routes for posts. And As you can see, these routes points the specific controllers.

Next stop is the controllers folder. Here I have the PostController. This basically has all the corresponding actions that exists in a Rails controller. The concept is basically exactly the same.

views - is however not exactly the same as in Rails. The modules are responsible for rendering the templates. And the templates are the files where the actual HTML lives. Views also acts as helpers. So any logic and functions that is needed in a template, will be added in the view.