To understand and try out entity component system approach the visual system was the first hurdle I had to take. Without that system you see nothing on the screen. Further more this system makes you understand how you should separate game logic from the visual stuff.
Don't store your spatial, the visual thing, in a component. Never ever. It is as if you would save Java classes in databases. It is backward. When ever you face your self to store a real thing in component it is a sign of wrong design.
Also think a bit bigger, if you start with a simple drawn character and you want later improve it all your saved game states are garbage then, because they still held the old crappy character. So a good decoupling helps you also to exchange your model at any time.
First thing you will need is a model component. The model component just contains the name of the model and not the model data itself. If you have the name you can load the model by this name.
The next thing you need is the position information. I normally place rotation and location in this component, but there might be cases where you don't want them combined.
I will not go into more details here as I did it in other blog posts, I guess it is clear anyway.
Now we need the system which cares about entities with a model and a position component and updates it when ever the position changes, an endity disappears or a new entity appears. The code of that looks like so
The most important part of this is
Which is for the local book-keeping of the models, which is done by the addVisibles, removeVisibles and updateVisibles methods. When ever an entity appears, disapears or changes it's position this system will be get triggered to update the view. Be aware that changing the model will trigger the update method but do have no effect, you would have to improve the update visible to see changed models as well (for simple games this is not needed).