Local stored singleton object

Ember Data
1

Hello, I’m new to Ember and I’m trying to store a simple model locally using ember-local-storage (setted up following this).

This is my model:

import { Model, attr } from '@ember-data/model';

export default class ScoresModel extends Model {
  @attr('number') scoreX;
  @attr('number') scoreO;
}

The idea behind it is being able to store the scores of a simple game while the user doesn’t close the browser. I would like to create a singleton object of this type when the app initializes (or load the existing one) so then I can show the scores in a specific route of my app.

From what I understood on the doc I can use this.store on route or controllers files. But I don’t know where would be the right place to create or find this Scores record so that it is available everywhere. The main part of the game is a component, I was hoping to be able to update the stored values there but I guess that won’t work, and then I should be able to access the object and show it from at the /scores route.

Any pointers in the right direction or links to tutorials/code that does something like this would be great. Thanks!

2

Maybe take a look at ember-pouch and ember-cli-blog

If your do ENV.remote_couch = null; here it works exactly like you want it to work and people can refresh their browser.

https://github.com/broerse/ember-cli-blog/blob/master/config/environment.js#L46

1 Like
3

Hi @moondaisy! Welcome to Ember!

I’ll try and point you in the right direction here with some high level overview of Ember Data concepts.

First off, Ember Data is very tightly coupled to Ember and some people tend do use it when it doesn’t always make sense. So basically all I want to say there is that you don’t have to use Ember Data at all, and even though it is very powerful and does a ton of awesome stuff it doesn’t fit all use cases so just be aware that you don’t need it for all occasions.

Next, the store. The store is an ember “service”, and a service is a class for holding long lived or global state that you can “inject” anywhere. The store is automatically injected into routes but you can manually inject it into a component as well so you can use it from a component too. The store specifically gives you access to Ember Data operations: creating models, fetching/querying models from an API, and caching models which you have already fetched or created.

Typically its recommended that you load a lot of your data in your routes. That is not to say you must, as I mentioned you can inject the store into components or other services or really anywhere, but most ember data operations are async which means they require a lot of extra ceremony to get right. That’s where Ember’s routing layer comes in, in addition to building mappings of views to URLs, it also handles all the async loading/error handling/etc for you so when the route template is rendered, you know you are working with data that has already been fetched. So if you know what you’re doing it’s great to fetch data in components, and there are some nice patterns for doing so, but it’s easier to stick with routes if the mappings make sense. So in summary you can think of a route as the thing that is responsible for fetching data, handling loading and error states, and then giving that data to the controller/route template.

The controller and route template together are more or less similar to a component class/template. The route model is automatically injected into the controller so the template has access to it. It’s not normally a great pattern to load data in a controller but it can be done in the same ways as in a component.

Anyway, back to your use-case. Honestly I’d say unless you A) want to practice using ember data or B) want to store a history of game scores instead of just the last or current one, Ember Data doesn’t necessarily fit your use case. You could read/write to or from local storage (preferably using a local storage service) wherever you need to. If you want to do it on app initialization somewhere in the application route might make sense, but if your main component is basically a singleton instance in the context of your app then you could just do everything in the component.

Anyway, hopefully that helps you a little bit. Let me know if you have any other questions about any specifics.

1 Like
4

Thanks for the detailed explanation, it made things a bit clearer.

I ended up using local storage as a service, and will leave ember data for some other basic crud example app in which it makes more sense.

1 Like