A responsive weather dashboard and mobile app.
Vanilla JS, Leaflet, OpenWeatherMap, OpenStreetMap, MVC, Sass
View Demo
·
Report Bug
·
Request Feature
Weather App
This is a weather application built to provide the user with many useful datapoints, including the current, hourly, and weekly weather forecasts, a weather map, weather alerts, location search (via name or map), and location bookmarking.
The application was built primarily using vanilla JavaScript, it also utilizes many packages and resources for specialized features including OpenWeather API for weather data, Leaflet for maps, and OpenStreetMap for map tiling.
Under the hood, it's a Model-View-Controller(MVC) architecture and utilizes parcel.js to implement the build package.
The app styling was built using Sass to take advantage of the mixins, nesting, and other features.
-
The user provides a location (either via search or browser location) and the app retrieves and displays the current weather, a current weather map, hourly forecasts, weekly forecasts, and current weather alerts.
-
The user is able search for locations via text input of city, state (only for USA), country code (e.g. "london, gb" or "reno, nv, us") or by selecting a location on the map in the search form.
-
The user can also bookmark a location for ease of lookup, which will be stored in the local storage of the browser.
-
The user may resize the viewport and view the app in a mobile or desktop/dashboard layout.
| Technology Stack | Description |
|---|---|
| JavaScript | |
| OpenWeather API | Weather and geocoding |
| Leaflet | open-source JavaScript maps |
| uuid | Universally Unique IDentifier |
| Parcel.js | build tool |
| Sass | stylesheet and style compiler |
Open the live demo here, or clone the repository, (node and npm are required).
Install npm packages
npm install
Start Server
npm start
Navigate to localhost
localhost:8080
This is a project I've been working on to refine my skills as a front end developer. Initially, the project scope was limited to forms and API calls using OpenWeatherMap. Over time the scope evolved and expanded to include a responsive dashboard layout, maps, search, bookmarks, and help functionality. Concepts incorporated included Model-View-Controller(MVC) architecture, mobile-first layout, SASS, reusable CSS components, state variable, ES6, modules, and error/action messaging to name a few.
- The application is built with a Model View Controller (MVC) architecture pattern to isolate and organize the flow control, logic, and view modules.
- Using a global state variable to control the application state. This variable stores the user's search query, geolocation (if enabled), current weather location results, and the bookmarked locations. Doing so keeps all the relevant data in one place that is easy to reference and pass as needed throughout the code.
- NOTE: After learning React, upon a revisit to this application, I realized that much of the design and execution of the application could have been done more efficiently in React as many similar concepts are used, i.e. components and state.
- Publisher/Subscriber Patterns - The publisher-subscriber pattern is utilized to call event listeners in the views on execution of the application. This allows for the event handlers to reside inside the views and when necessary the handler would execute a callback in the controller to run a desired task. For example, on app load, the saved view event handler is called and sets up the event handlers for actions in the saved view, i.e. calling a saved location, removing a saved location, or sorting the saved locations.
The layout of this app has been designed mobile first such that it works well on a mobile sized viewport and when the viewport size is detected larger (i.e. tablet or desktop) the layout will switch to a grid-like dashboard.
- mobile with swipe navigation
- desktop and larger screens dashboard layout
Throughout the development of this project, there were many challenges that arose, from layout headaches to broken functionality.
Navigation & Menu Positioning
- Building a responsive navigation and menu proved challenging as the layout design had navigation inside and outside the rendered weather component, depending on if the weather had been rendered or not.
- For example, if the user blocks their location, the app will load and render the menu at the bottom (in mobile view) or in the lower right corner (in dashboard view). When the user selects a location and the weather loads, the navigation menu will hide in dashboard view and appear in the component itself.
- In order to achieve this, the menu had to be rendered twice and hidden depending on the screen size using media queries. Using CSS grid properties it was not possible to render the menu once and display it inside the component as all grid children have to be inside the parent (which would not have been loaded).
Refactoring and Creating CSS components
- Refactoring common styles into components, modularizing scss, and using BEM class naming convention and class prefixing.
- This proved to be a pretty difficult challenge, as there was previously a lot of repeated code that needed to be reduced down to classes that could be reused. Recognizing repeated CSS, and determining the property names and structures to ensure the ability reuse classes took some time to figure out. Class naming followed the BEM naming methodology and where appropriate layout classes were prefixed with 'l-' or 'c-' for layout or component classes. There is still some refactoring that could be achieved, but the main components have been refactored.
Scope Creep
- A very important lesson learned while building this project was that planning is the most important step, and should be done early in the build (ideally before you begin coding anything). Since this is a practice project, it was very easy to expand the scope of the project on the fly as I learned new concepts and technologies. This resulted in excessive scope creep on the original intention of the project, and likely resulted in a messier final (for now) application. In summary, I learned that a truely well developed application is planned and limited in scope to ensure features are executed correctly.
This is the basic usage of the application:
On load, the user will be prompted to allow or block their location.
- If allowed, the application will automatically retrieve and display the weather.
- If blocked, the application will allow the user to search for a location or open a previously saved location from their favorites.
To search, the user must select the search type radio button (i.e. location name or map location). Then provides the location name in the text input (e.g. "london, gb" or "reno, nv, us") or click and pin a location on the map (as seen in the screenshot).
To bookmark a location the user must click the location name or bookmark icon in the current weather box.
- Clicking an already bookmarked location's header (title or bookmark icon) will remove the location from the bookmarks.
- The use may also remove a bookmark by clicking the red icon to the right of a location in the bookmarked locations view.
To load a bookmark, the user must select the desired location (if previously bookmarked).
In the mobile view, the user may swipe left and right to navigate to the search and bookmarked locations views or select the menu toggle on the bottom and use the icons displayed.
On a larger viewport or desktop, the user can use the menu toggle which will display the navigation icons.
Additional features may include:
- light/dark mode toggle
- ability for the user to drag and/or hide certain weather elements such as the map, hourly, and weekly displays
- ability for the user to create a custom name for a location, e.g. 'Home', 'Work', etc.
- ability for the user to pin favorite locations to the top of saved locations component
Known items to refactor:
- the styling source code can be refactored and cleaned up
- the sort saved location logic is a bit clunky and difficult to follow
Distributed under the MIT License. See LICENSE.txt for more information.
