Not sure how to use

[cjroebuck]

Sorry for being dumb, but im not sure how to use this, I have my node server running on port 3030, then I run livestyle on port 3000 with debug mode, I manually update some CSS within my current working directory but there is no change to the site and no debug lines in the terminal window... Have I missed something!?

[Munter]

We certainly need to document the command line arguments better.

To run against your local server on port 3030 you will need to use '--proxy http://localhost:3030'

Furthermore you need to supply a document root for livestyle from which it bases root relative paths. Ideally you supply the '-r' parameter with the directory that is also the document root of your local webserver, then the paths should match up correctly.

If the local directories don't match the mappings in your web root you'll need to apply mappings with '-m'.

If you still can't get it to work I'd like to see what paths your css is server from on your localhost:3030, your projects directory structure (only to css) and the comman line arguments you start livestyle with.

If the css is where livestyle assumes it should give you lots of debugging logs.

[erkie]

Do I have to include the livestyle-client.js in my project or is the livestyle server set up to serve it? I tried through http://{livestyle-host}:{port}/livestyle-client.js and I get "Cannot GET /livestyle-client.js". The documentation should be clearer on how to do this.

[Munter]

The server injects the client into all served html. If you for some reason need to run livestyle in a setting where you can't start a server, you can manually put the client code on the page and it will fall back to polling.

And you are right that this should be clearly documented

[erkie]

So livestyle is purely for node apps? Or how would you run it when using a rails server, for example?

[Munter]

Proxy mode. You run livestyle from the command line and tell it to --proxy http://yourRailsServer

[erkie]

I see! So you run

livestyle --proxy http://localhost:3000 -p 8000

And then go to http://0.0.0.0:8000/ instead of the usual http://localhost:3000/. Wouldn't it be better to just serve the livestyle-client.js from the server, so I can add the script tag where it suits me, and not have to go through the proxy at all? Like Vogue. I see that it can be useful when editing just static files, but for big dynamic projects it seems a bit cumbersome.

[Munter]

One of our prime goals with this project was to give the flexibility of live updates without having to make any change to your own code base, since adding development specific code into your code base only leads to potential errors if it accidentally gets into production.

An added benefit of being able to run as a proxy is that you can cross network gaps more easily. As an example you could point livestyle at your production system and tweak the css from your local checkout and still have it update your css live with live data to show from the backend.

Lots of systems need to run build scripts and deployment across networks with lots of lag before the css file actually gets to the server you are developing on. Livestyle lets you skip all that

[erkie]

I understand the flexibility with it. The way I've been using Vogue is to: include the javascript in a "if is_dev?" block so it's only included in development, and start the server in the public/ directory of the project. This way I never have to care about it. If I want to change a style I just have to open the CSS file in the editor and change it/save it. With the proxy option in livestyle I have to be on a completely different host to begin with. Debugging becomes more difficult and it loads everything a bit weird.

When I tried it on the site I'm developing it took a lot longer for the page to load than usual. It loaded the styles, unloaded them, so I got a flash of unstyled content for few seconds, and then it loaded them in again.

It would be nice to have the option to serve it like vogue. And possibly document the new "flow" you have to get used if using the "standard" option. I would never have guessed that you used it in this way, it doesn't say so anywhere. I believe that it make more sense to have the "proxy" way as an optional feature, and advertise the "just add one script element to the page" as the default, which makes much more sense and is less troublesome for a developer.

The way you described it is a nice feature to have, but it's more for power users.

[Munter]

I am having difficulties seeing why the workflow of starting the server and adding a javascript to your page is less troublesome than starting a server and use that instead. But I am the architect, so I have a natural bias towards the current solution. I don't see any difficulties in special casing the livestyle client url in the server and use it in a setup that is similar to Vogue. It's just yet another setup to document. I'll open an issue for it.

About the slower load times. I noticed, but didn't really care, since the usage during live styling is more about loading the page once and use the built in functionality of css refreshing after that, which is fast enough. I'll open an issue on that one as well though. It makes no sense that a local proxy should slow down page loads.

[Munter]

On second thought, doesn't the Vogue setup limit your ability to set up the server where you'd like? What if I wanted to start the livestyle server on a machine other than my localhost?

[erkie]

As long as the script tag points to the host/IP and port that vogue is on it works. Say for example that I'm testing locally on http://localhost:3000/ and my internal IP is 192.168.100.127. I can access my development server by http://192.168.100.127:3000, and since vogue is on 8001 I just have to make sure that it's pointing the correct IP: http://192.168.100.127:8001. I have it set up in the /etc/hosts files on my local machine and my other testing machine so they point to the same server. So what I really access is http://local.mysite.com:3000/, and point vogue to http://local.mysite.com:8001/ and everything works nicely!

So I haven't had any problems with testing on different machines. I actually did the testing for IE9 compatibility on a laptop that accessed vogue from my Macbook.

The way you described might be easier if you fire up livestyle solely for the purpose of writing CSS, but with the script tag I have added it once, and only have to make sure that the vogue server is running. It works great for spontaneous CSS editing.

[gustavnikolaj]

I added an issue (#40) for adding examples of how to use livestyle in the readme.

I couldn't find any actionable tasks in this thread besides that. If there's something I have missed feel free to reopen or create a new issue.