Closed defunctzombie closed 10 years ago
are you saying that date
is now on the view? otherwise if its still a custom formatter function that doesn't need to be on the view, then it feels too confusing to know whats custom and whats not
If I understand correctly from the code, the current formatters usage will simply translate the pipe into a call on the view (maybe also on the model). I agree that formatters could be more generic and maybe we need a way to specify that, but the above was just going on the current code.
Either way, I think the non data-text syntax is clearer and will make fewer codepaths to evaluate and test.
@ianstormtaylor I checked the code again, and the current version uses formatters defined in the view. Would be nice if that wasn't the case. Maybe we can do something with the new .use
stuff.
Personally I'm I fan of data-text
because it lets you specify some default text to show before reactive runs so the users don't see a flash of Hello {{user.name}}
on pages with a lot of bindings or a slow connection
<span data-text="Welcome back, {{User}}!">Welcome to MyApp</span>
@ilsken I don't put the templates on the html page, I have them required in my js files so I never have html shown to the user which did not go through the rendering. If you are putting templates on a page I think the typical approach is to put templates in a script tag and not leave them dangling on the page. Even with data-text your users could see flashes of un-rendered content and rapid changes since the page will first render and then you will apply bindings which could radically change the initial rendering.
Good point, does this not work though?
<div>{{ some_date | date:'%Y%M%D' }}</div>
I would of assumed that interpolated text works the same way as the data-text
binding
@ilsken that does not correctly work nor do I think it should. I think the following is more clear and falls in line with the fact that {{ ... }}
is just executed as regular js
{{ date(some_date, '%Y%M%D') }}
It also makes it much clearer what happens because right now the format syntax doesn't actually look like a function call with arguments which is all it is.
I agree with you 100%, I was just expecting that interpolation and bindings wouldn't have a different syntax for calling formatters. Although you could also argue that the pros of a cleaner syntax for a common pattern such as filters outweighs the loss of clarity.
I would prefer
{ date(some_date, '%Y%M%D') }
although need more typing, but easier to get understand. In Angular the formatter works as filter and they could be chained easier with |
syntax, don't think that's really necessary as we can always easily use one format function and more filters would make the code harder to debug.
This will be removed in my work on reactive-next.
I think the data-text binding is redundant and we can do away with it. Since we have interpolation now I don't see the value.
The one remaining thing it does is "formatters". I think we can better implement this using clearer function calls.
The current way (taken from a test)
Instead I propose (via interpolation
The latter is what the former is turned into behind the scenes and to me is easier to understand since users are already familiar with interpolation being able to call a function.