For anyone on the upgrade path from Surface version 0.3.* or less to 0.4.*, I created this mix task which converts the deprecated “atom-string shorthand” syntax.
This:
<SomeComponent atom_prop="warning">
is turned into this:
<SomeComponent atom_prop={{ :warning }}>
In 0.4.0 there is a deprecation warning, but in the upcoming 0.5.0 it will fail compilation.
https://github.com/paulstatezny/surface_atom_shorthand_converter
I just read this (Proposal for syntax changes in Surface v0.5 · GitHub). So the plan is to move from the mustache style syntax {{...}} to svelte style syntax {...}. I want to know if the old style will be supported indefinitely, or do we have to migrate all code at some point?
Surface v0.5 has already been released!
An overview of the new syntax can be found at Template Syntax.
We advise all users to upgrade to the new version as the old syntax will no longer be supported.
To make the migration process as smooth as possible, Surface v0.5 ships with a mix surface.convert task that converts the old syntax into the new one.
For detailed instructions on using the converter, see the Migration Guide. Please make sure you read the instructions before running it.
Full CHANGELOG can found at surface/CHANGELOG.md at main · surface-ui/surface · GitHub.
Thank you for this upgrade. I recently upgraded a project to version 0.5 and it took less than an hour (small project with ~15 components). I had to mind the quoted="{@values}" though. Really love the new syntax.
@code-shoily did you use mix surface.convert or did you replace everything manually? The converter should have handled those interpolations too.
I tried mix surface.convert at first, but I recall it did not convert some of the {{ }} so I tried the manual process instead. I had put that in my todo list to circle back to it and inform if needed. In fact, I have a version 0.4.0 branch and I have some time to play around, I will just run mix surface.convert on it and come back with diffs 
I could totally be wrong about it too.
Update: I was!
So I just did it again, looks like it was my fault, I had made a mistake on the command I ran. First I tried mix surface.convert which didn’t convert the sface file but then when I added the path argument I made an error (missed the **) there which was causing the files to not convert. I tried the command right now and it works.
(I tried mix surface.convert "lib/**/*.{ex,exs,sface}" "test/**/*.{ex,exs}" pasted from the docs). Well, I don’t regret manually changing though, gave my muscle memory some cool adjustments but I totally recommend and mix surface.convert. Thank you again.
@msaraiva, it appears to me that the new surface syntax is moving to be very close to that of svelte. I really appreciate the trend as the resemblance can increase productivity and lower barrier to entry. However, I see there is still some discrepancies. In Surface, we have:
{#if @a > 0}
...
{#elseif @a < 0}
...
{#else}
...
{/if}
but in svelte we have:
{#if a > 0}
...
{:else if a < 0}
...
{:else}
...
{/if}
the difference is subtle but still there. It could throw people off. Since we are making the new syntax anyway, why don’t we try to follow existing convention closer?
We can’t have the same Svelte syntax because it would be ambiguous as there’s no way to distinct, for instance, whether {:else} is a sub-block for {#if} or an ordinary expression containing an atom :else. Having a different embedded language (Elixir vs JS) imposes different choices when defining the syntax.
Besides, I don’t want to have our templating solution fully anchored to any specific language as this would limit our choices as well as bring false expectations about its use and evolution.
We certainly bring features inspired by different languages but we always need to make sure they are feasible in our context 