-
Notifications
You must be signed in to change notification settings - Fork 232
RFC: Using statics, top-level members, enums in a template #374
Comments
What happens if exported symbols collide with either fields/methods on the controller class or each other? (Granted the analyzer plugin could probably help with this) EDIT: i.e. do you prefer exported, or prefer the specific kinds of exports. And if there are collisions, is this a warning or error built into angular? |
I think we'd prioritize the instance member. You could always use |
I note that using final variables for Intl messages is not a good idea, because it introduces a race condition between locale initialization and variable initialization. |
I think the assumption we make here is that you are configuring your locale prior to bootstrapping Angular. What about in that case? |
It will be great to have access to Enums, etc! A few comments. (1) As for shadowing, I'd suggest that we follow whatever the rules are in Dart. (2) Just to clarify, shouldn't exports: const [
'topLevelField',
'SomeEnum',
], (3) Finally, you give
as an example. Would you expect that to work if it were declared cc @kwalrath |
The exports list is designed to have actual references to const objects so that the compiler can resolve them at build time and know what imports to add to the generated template (as well as optimize based on their types). This also means you don't need to ignore any unused imports in your file or anything like that. It does have the downside of only allowing you to export const objects to the template, but that still supports all the major use cases I think? |
+1 That does bring up a different point, should statics of the class itself be visible, i.e. without including in class Comp {
static const okButtonTitle = 'OK';
static String formatObject(object) => ...
} <button>{{okButtonTitle}}</button>
<button>{{formatObject('...')}}</button>
As @jakemac53 mentioned, we want it to be actual references to the objects you will be accessing. Similar, to say, the
Yup, definitely!
|
I don't think the If you think about it, that's essentially what the I mean, you could maybe even just get around the whole problem if you assume all imports are used, and just copy all of them over into the generated template. The bigger problem here is privates:
I think by not having an Alternatively, we could allow Also: any reason not to allow all things dart not currently allowed in templates?
? |
There are a couple potential issues that I think would require a deep investment into the analyzer to resolve fully.
The same reason we have the |
How so? If you see import 'package:angular2/angular2.dart';
@Component()
class Comp {} There is no clear way to find either import 'package:angular2/angular2.dart';
// ignore: unused_import
import 'format.dart';
// ignore: unused_import
import 'messages.dart';
class Comp {} or export 'format.dart';
export 'messages.dart'; Both have obvious immediate downsides.
We do that today, we actually don't want to anymore - we want to generate a Dart file that passes analysis and looks human readable (mostly). The only way we could truly due this is use
This is already a problem: You can't use privates in
You tell me :) We'd like to transition the compiler to use |
Ah, yes, that's true. I'd be part tempted to include imports in the template, myself, to solve this problem. But I tend to really give angular a lot of credit in being its own unique language rather than a framework...the frameworkier side of thought aligns better with an Also could create problems with testing, if your template itself had the ability to import production code. Though if most of what its importing is enums, that certainly would be unlikely to create problems. Other questions for the export field, any plans to do aliases?
note: I will say, I get a bit of a funny feeling because I think this general concept is so far conflating values with identifiers. Sure, if I don't like the default name, or have a calculation I want to give a name (like But what if I do
Now is it accessible in my template as And what if I do
Is it an exported identifier or an exported array of exports? Can I do And if its the formost, what happens when I export an array of Some fuzzy stuff here, could get confusing to spec out, and could get confusing to use. I guess my thought is that dart imports have already solved this problem in a clear way. |
We did consider this, i.e. <import src="messages.dart" /> That did seem like a (1) lot more work and (2) introduced more non-standard HTML to understand.
We should be able to support import aliases, for example: import 'messages.dart' as messages;
exports: const [
messages.FooMessages
], <div [title]="messages.FooMessages.someTitle"></div> I think that would work for most cases, no?
|
I guess that would be OK. As long as you're sure it's true, are comfortable
relying on lazy initialization timing for correctness, and you can never
change locales at runtime. And it's not something that would be detected by
tests, or by developers, because it only happens in non-English locales and
the failure mode is that some messages aren't translated, some of the time.
…On Thu, May 11, 2017 at 5:55 PM Matan Lurey ***@***.***> wrote:
@alan-knight <https://github.com/alan-knight>:
I note that using final variables for Intl messages is not a good idea,
because it introduces a race condition between locale initialization and
variable initialization.
I think the assumption we make here is that you are configuring your
locale prior to bootstrapping Angular. What about in that case?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#374 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADUKeGk0CY2Er72LOjBC0nTqsljSr4xoks5r463tgaJpZM4NYs6k>
.
|
It still feels weird to me, because It seems weird to me that an array could do similar things, because arrays are values and not identifiers. Its also not composable, meta-programmable, because you can't merge two arrays of identifiers. You get into the question of intent, was this intended to be read as a value or not? But enough of me saying "hey I gave a weird feeling". Here's what I agree with:
For instance, my What about a radical idea, annotating the imports?
this does still result in unused import warnings, but I would consider that a bug. I do dislike the level of disconnect between the component and what's exposed to it. But it feels less boiler-plate-y to me, and it no longer conflates values with identifiers. Edit: I was mistaken about easily supporting all enums via If you annotate the import, its easy:
and I would consider this extendible/metaprogrammable/composable, because all it takes is adding However, if an
then there's no way to avoid repeating yourself without getting back into arrays of And when |
If we go with imports inside the templates, I'd probably recommend
over
in terms of purely opinionated points of discussion :) |
I would prefer keeping imports out of HTML |
Giving a small update: We have a proof of concept of this working, mostly, so it's likely we'll go with the |
Does this also solve the case for static component class members? |
Yup: #911 (comment) |
This is potentially planned for
4.0.0
, pending feedback and experimentation.tl;dr: We'd like users to be able to refer to:
... within their template (HTML).
Configuration
We'd need a way to tell the template what symbols to expect. There are several (unsatisfying) ways to solve this when it doesn't belong to the current library - for example,
import
with an unused import, orexport
. We're planning on settling on anexports:
list on@Component
:Examples
Top-level fields and functions
Enums
Static members and functions of a class
Considerations
/cc @MichaelRFairhurst, for considerations for the
angular_analyzer_plugin
.The text was updated successfully, but these errors were encountered: