rethink live development server provider interface

[joelrbrandt]

(cc @redmunds @njx @gruehle)

We have a preliminary interface for live development servers, but we probably want to improve (or maybe elimate!) it going forward. I'm creating this bug so we can track possible improvements.

One thing that I've already found a use case for is: We could modify (and probably rename) the readyToServe call to take in a filename and return a promise that resolves to a URL (or rejects if the server doesn't want to handle the file). Doing this, an extension developer could implement an extension that, e.g., figures out what path to serve a Ruby on Rails file at. These files don't have a 1:1 mapping to urls, but an intelligent extension could do the mapping.

@alltom wants this.

[redmunds]

There are a pair of complementary functions in LiveDevelopment.js called _pathToUrl() and _urlToPath(). We could make similar calls part of the LiveDevServerProvider interface so providers could override this behavior. Also move the existing functions to a utility file so existing providers could call them as the default behavior.

[pthiess]

@joelrbrandt I wonder why we pre-assign it to Sprint 22 with a low priority?

[joelrbrandt]

@pthiess I want to work on this if I have time during sprint 22. But, I'm not sure that I will. Working on it would benefit some of the research work I'm doing with @alltom, but I don't think it would have near term end-user benefit.

So, I put "low priority" because I don't think it's high enough priority that someone else on the team should work on it. I also wanted to signal that I might kick it out of the sprint.

[peterflynn]

In addition to making the project file -> URL mapping more flexible, we may also want to consider supporting the default HTML file user story -- i.e., the current document when you invoke Live Development may not be the document whose corresponding URL we decide to launch.

[alltom]

Here's my take as an extension author.

I don't think we're anywhere near the point where supporting new server technologies can be boiled down to writing adapters. Even the assumptions like those inherent in the existence of pathToURL and urlToPath don't hold in non-trivial Rails projects because of the asset pipeline. However, Brackets already provides very rich APIs for live editing (Editor, Inspector, Agents, etc) that extension authors could already use to interact with server-generated pages, if only Brackets would let them. It wouldn't take much:

• Allow an extension to specify the full URL to load when the lightning bolt is clicked. Currently, Brackets requests a base URL, but in general, tacking the relative path of a file onto the end of an URL doesn't make sense.
• Allow an extension to decide whether the Live Development connection should be broken when the tab's URL changes. Easy mode is to allow an extension to specify that the connection should stay open until the tab is closed or the lightning bolt is clicked again. Currently, Brackets disconnects if the user navigates to another page.
• Allow an extension to squelch Brackets' impulse to re-open the browser tab when the user opens an editor for a file ending in '.html'. Brackets can't tell whether that file is already open in the browser, and the current server provider might not open it anyway if it doesn't make sense to. I don't think Brackets should do this under any circumstance, but that's a separate issue. :)

I should mention that my JavaScript debugging extension already works with Rails (for the moment) by taking advantage of the fact that the Inspector connection isn't severed when Live Development enters an error state (probably a bug), which happens when the tab navigates to a new URL. The exceptions in the log about a frame disappearing during the tab transition don't prevent the Inspector connection from operating correctly, so I just reset my extension's state and wait for the page load event to start everything up again. I can browse a Rails site in Chrome and switch editors in Brackets independently without the extension losing track of what corresponds to what.

I also have a request: the user should be able to start Live Development even if no editors are open. In a Rails project, it makes sense to open the root URL, but Brackets doesn't consult with any extensions about whether that should happen unless an editor is open.

[peterflynn]

Removing Sprint 22 milestone since it's not clear Joel will have time for this and it's not viewed as required.

[tobya]

If I could add my 2 cents to this.

I took a look at brackets and love what you guys are doing, but this issue makes it impossible for me to use the live preview if I use brackets for my development work. I can provide my story and some suggested solutions to try to see if this could be resolved. Perhaps it can be added to a later sprint.

I have a bespoke php application running internally in our network. My structure is as follows

pages - php pages that are mapped to urls. templates - smarty templates that are used by php pages in pages directory for html scripts - any included js

At the moment the live preview only makes sense if I am editing a php pages in the pages directory, as this maps directly to a url that makes sense in the context of my application, if I edit a template html file in the templates directory the live preview will show my template file which is not of any use. I can see this being similar for a lot of systems including drupal and rails projects but have a differnt underlying technical explanation.

I would propose a very simple solution.

Live preview is locked or unlocked.

When live preview is initially started it is unlocked meaning it does what it currently does eg changes when the edited file is changed.

By clicking the live preview lightning icon you can lock it, this means live preview will continue to show the same file and refresh each time you change any file in the editor (a padlock icon could be added to the lightening bolt). Hovering the mouse over the icon will tell you what file it is locked to. Clicking again will unlock and return to changing for each change in the editor.

This simple change would certainly work for myself and would likely work for other bespoke and some opensource systems.

Keep up the good work.

[njx]

@tobya -- I like the general idea of being able to "lock" the current preview file, and it lines up with other feedback we've gotten about similar use cases (e.g. WordPress sites).

@adrocknaphobia -- I wonder if we should move this live development workflow issue higher on the backlog, or at least see if there's some low hanging fruit here, either along the lines of Toby's suggestion or other ideas @joelrbrandt has mentioned in the past. See also #2103 and this Google Group thread: https://groups.google.com/forum/?fromgroups=#!topic/brackets-dev/KlZGEvUYjLc

[njx]

Also see #2321.

[njx]

FYI, I think the most relevant card is https://trello.com/c/uKewlref. Already reasonably high on the backlog, but it might be worth doing a quick brainstorm or research spike to figure out if there's low-hanging fruit we could get in soon.

[tobya]

In order to facilitate systems that use mod_redirect urls a lot such as wordpress, drupal, codeignitor etc it would probably be necessary to allow a specific url to be specified for live preview, this specified url could then be locked in the fashion described above.

I think implementing this would get you a lot more beta users.

[JayGeorge]

I really agree with tobya on this one. I am really excited about Brackets and want to use it for live CSS editing with WordPress sites, but being thrown off the page when changing files kills it. Consequently I can't really scream and shout about it to front-end web designers that design in-browser until this issue is sorted.

Brackets reminds me of Espresso (macrabbit.com/espresso/) in the way you can get live changes when you edit CSS. The way that Espresso implements it is that you can just override any URL in their browser preview window, explicitly stating the URL. If we have a lock mechanism (at least in the short-term) this would effectively achieve the same desired effect.

[tonyv69]

@SparrwHawk @tobya I just wanted to agree with the above - This is an important feature for developers / designers working on dynamic sites ie WordPress etc... with out this functionality I'm unable to use this as my day to day editor/IDE works great as a SandBox text editor for me at te moment.

Loving Brackets, keep up the good work!!

[DigiSquid]

I apologize for resurrecting an old topic, but I'm a Wordpress dev and, while I'd love to use Brackets as my primary editor, it just isn't possible with the current implementation of Live Preview. Every time I touch a template file, Brackets triggers a reload and everything breaks.

As I'm personally most interested in live CSS editing, ideally I'd like a way to either lock my preview to whatever page I'm on, or take an approach like Espresso where I'm manually overriding the CSS. Either of those solutions is far more ideal than the current implementation that assumes everyone is building static HTML websites where a file = page on the server.

[njx]

Marking needs review--there's a lot of activity around this issue. We should consider up-prioritizing the associated backlog item.

[peaceofcode]

Where are we at with this issue that @DigiSquidinc has raised? This could be achieved by setting a directory or multiple directories where the styles are located and then have an automated ## comment-out feature so and the edited line could go above or below the ## commented-out line.

The work that Lee Brimelow talked about would be mind blowing with dynamic development. http://www.youtube.com/watch?v=kXTP8XqrSwE&feature=c4-overview&list=UUyR7pHbcXgpGy1wgqInf3Wg

In my opinion this easily ranks as one of the most important issues. Adding UNGIT and GIT SYNC from a Bare REPO is about the same level of importance..

[mathetos]

Just pulled out Brackets again today to work on a WordPress theme and encountered the same issue that @DigiSquidinc mentioned over a YEAR ago. Is Brackets dying a slow death, or is just this one (fundamental) issue that affects all CMS's (not just WordPress) being ignored for some reason?

[DigiSquid]

It seems to me that getting Brackets live preview to work with CMS systems is a low priority for the devs (heck, it's literally marked low priority here). So I'm going to guess that their focus is primarily static site development. I personally haven't built a static site in years, so I've pretty much stopped using the app altogether - though I do still check in on it from time to time. :-)

[peterflynn]

@mathetos The Brackets community has never been bigger or more vibrant. But if you look at the Brackets feature backlog, there are over 400 feature ideas listed. Even in a year, we can't build them all. (Lots has been going on -- check out the history board, everything left of the Sprint 35 column was done last year! -- but there's lots more to do, so it's a matter of prioritizing).

In this case the relevant backlog items are:

• RESEARCH: Make Live Development Work For Router-Based Technologies
• Live HTML updating with user web server (Node, Rails, etc.) & static HTML
• Live Development with dynamic server side pages

This is all complex work, so it can't happen overnight. But one thing people can do to help raise the priority is to upvote those backlog stories! Currently none of those stories even rank in the top 50 by votes.

Since this issue is actually redundant with what's on the backlog, I'm going to close this. There's lots of great discussion above though, so I'll link back here or try to summarize the discussion in the backlog cards.

[peterflynn]

Also see Live Preview: using a local server is confusing on the backlog. If we're smart about how we address that, it could help with these router/CMS situations too.

[DigiSquid]

Currently none of those stories even rank in the top 50 by votes.

Which really surprises me because I haven't come across anyone still developing static sites professionally in ages, nor have I had any requests from clients for this type of work. Obviously that's anecdotal, but I assumed that working with dynamic sites/frameworks was more or less the norm these days.

Even still, I respect that my workflow doesn't necessarily everyone's workflow and clearly those of us requesting this feature are in the minority.

[peterflynn]

@DigiSquidinc Nonetheless, I do agree it's an important workflow that Brackets should care about supporting. More upvotes will help. Also, Live Preview is currently undergoing some flux due to the new "Multi-Browser Live Preview" functionality that's in progress. Once the dust settles from that, I'd hope this is the thing we'll tackle next within the Live Preview area.

In addition to upvotes of course, since this is open source people are also welcome to take the initiative and put up a pull request or write up an architecture/spec proposal! That goes a long way. Starting a discussion about the implementation and behavior, e.g. on brackets-dev, is a good first step for anyone interested in that.

[DigiSquid]

Thanks for the feedback @peterflynn. If Live Preview supported server-based technologies, Brackets would easily become my primary editor. But, without it, I simply can't use it. So I do hope that the value of this workflow gains some attention.

As it stands, there are virtually no apps or IDEs on the market geared towards interface designers / developers working with server-based technologies. So we're forced to use hacky third-party workarounds or manually reload our browsers each time we need to see an update.

If I could replace this clunky workflow with something like Brackets, I'd be thrilled.

[ghost]

Only just stumbled upon Brackets and, whilst it seems like a great editor, I have to echo what others are saying really.

I work solely with WordPress and any editor I use must be compatible.

Live preview is something that would be greatly welcomed, but the current implementation of it in Brackets just doesn't work well with WordPress at all. Ideally, it shouldn't change the file in live preview to the one you are editing, this just doesn't help at all. It should stay as showing the site itself in the live preview screen and just allow edits to be added automatically.

[baberuth22]

This issue certainly shouldn't be closed. I still can't live preview my Wordpress sites.

A simple solution would be allowing the user to specify a file -> url array.

Eg. template-wall.php => /wall

Easy right?

[Taariqq]

Hi guys!

Are you guys using an alternative that is better? Is vscode doing the job? Did someone address this issue before Brackets was (perhaps) abandoned?

I am new to the world of web dev and just starting out with wordpress. I was thrilled with the live preview in Brackets and that was the main reason keeping me from switching to vscode.

Does anyone have a solution that will help me stay with Brackets?