coursier sbt fails with scala-native build

https://github.com/scala-native/scala-native/blob/master/project/build.sbt#L15
  at coursier.ivy.PropertiesPattern$Parser$.<init>(Pattern.scala:127)
  at coursier.ivy.PropertiesPattern$Parser$.<clinit>(Pattern.scala)
  at coursier.ivy.PropertiesPattern$.parser(Pattern.scala:142)
  at coursier.ivy.PropertiesPattern$.parse(Pattern.scala:146)
  at coursier.Tasks$.coursier$Tasks$$globalPluginPattern$lzycompute(Tasks.scala:300)
  at coursier.Tasks$.coursier$Tasks$$globalPluginPattern(Tasks.scala:281)
  at coursier.Tasks$$anonfun$resolutionTask$1.apply(Tasks.scala:460)
  at coursier.Tasks$$anonfun$resolutionTask$1.apply(Tasks.scala:317)
  at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
  at sbt.$tilde$greater$$anonfun$$u2219$1.apply(TypeFunctions.scala:40)
  at sbt.std.Transform$$anon$4.work(System.scala:63)
  at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:228)
  at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:228)
  at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:17)
  at sbt.Execute.work(Execute.scala:237)
  at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:228)
  at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:228)
  at sbt.ConcurrentRestrictions$$anon$4$$anonfun$1.apply(ConcurrentRestrictions.scala:159)
  at sbt.CompletionService$$anon$2.call(CompletionService.scala:28)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  at java.lang.Thread.run(Thread.java:745)
[error] (nscplugin/*:coursierResolution) java.lang.NoSuchMethodError: fastparse.all$.parserApi(Ljava/lang/Object;Lscala/Function1;)Lfastparse/ParserApi;
[error] Total time: 0 s, completed Mar 21, 2017 3:57:09 PM

Maybe a bin compat issue with fastparse. It is shaded in the latest release of coursier though (1.0.0-M15-5), which works for me with the current master of scala-native.

(Except that I'm getting some resolution errors when running update because of some snapshot dependencies - but no bin compat issues).

Cool the snapshot problems are solved with sbt rebuild. I'm trying it out locally now.

It still fails. This time is a duplicated compiler plugin in the classpath.
To reproduce:
sbt rebuild sandbox/run

Wow that was fast! How can I try? Do you have nightly build?

Ah, it was automatically closed, I was getting some linking errors last time I tried your command. I was about to try again (from another machine).

But https://github.com/coursier/coursier/issues/487 could help.

you need some dependencies: http://www.scala-native.org/en/latest/user/setup.html#installing-llvm-clang-and-boehm-gc
brew install llvm bdw-gc

I'm still getting linking errors:
[info] Compiling 1 Scala source to /Users/alexandre/projects/scala-native/sandbox/target/scala-2.11/classes...
[info] Error: unable to load class: scala.scalanative.nscplugin.NirPlugin
[info] Ignoring duplicate plugin nir (scala.scalanative.nscplugin.NirPlugin)
[info] Linking (33 ms)
[error] cannot link: @Test$::main_class.ssnr.ObjectArray_unit
[error] cannot link: @java.lang.NoSuchMethodException
[error] cannot link: @java.lang.NoSuchMethodException::init_class.java.lang.String
[error] cannot link: @java.lang.String
...
[error] unable to link
[error] (sandbox/*:nativeLink) unable to link

You can test yourself by checking out the sources of coursier, changing the version in version.sbt, running sbt ++2.10.6 publishLocal, then using this version of sbt-coursier from the sources of scala-native.


Move SdmGoal event ingestion to a global automation

These need to be in one place, and it needs to be durable, so that the events can be queried by multiple automations.
Also move the CopyGoalToGitHubStatus there, because that also needs to be in one place. Have it skip any goals with an empty externalKey.

SdmGoal got moved to a global automation. That part is done.
Moving the CopyGoalToGitHubStatus to the global automation makes sense too.


Remove MultipleErrors

Don't merge me until SlamData is updated please : )

The MultipleErrors constructor is something the backend explicitly sends. If we now treat every error from Quasar as if there are multiple will introduce a lot of dead code.
What is the motivation for this?

Removing interleaving concepts I think.
Why should we preserve 1-1 mapping with quasar JSON if it's possible to separate?

What interleaving concepts? It's called a QError so I'd expect it be an error from Quasar. Initially I thought you were going to change | MultipleErrors (Array QError) into | MultipleErrors (NEList QError) which made sense to me. Afaik the MultipleErrors constructor only appears in the compilation errors though, so you're going to be handling them everywhere now, when they only rarely occur.

regarding "handling them everywhere" its not such a horrible thing given all the nice instances that come with NonEmptyList.
but for now i'll just add foldable. i kinda get both arguments but i prefer NonEmptyList QError for reasons i might want to try to explain when i'm less busy : )

What interleaving concepts?

Error type: Forbidden and PaymentRequired is explanationary tag

Error count: MultipleErrors is aggregational constructor

Encoded JSON with those errors

PS representation

Frankly my main concern is about MultipleErrors [MultipleErrors [MultipleErrors ... such thing has no sense. All that NEL.singleton ErrorCstr could use smart constructors errorCstr = NEL.singleton ErrorCstr and handling could use folds everywhere.

See this in the context that I have the task to refine the way we communicate errors with Quasar together with JR. https://github.com/slamdata/slamdata/issues/1457

Error type: Forbidden and PaymentRequired is explanationary tag

That's not going away because we make all requests return a NonEmptyList of errors.

Error count: MultipleErrors is aggregational constructor

It maps exactly to an error Quasar returns. Just treating every request as if it returns multiple errors is just lying to ourselves. This data type is not something we construct, it is created by Quasar and we parse it.

Encoded JSON with those errors

The fact that we stringify  and then wrap up Quasar errors in JavaScripts Error constructor is ridiculous,
but that's not going away because we make all requests return a NonEmptyList of errors. That's a problem with the extremely String heavy error handling here.

Frankly my main concern is about MultipleErrors [MultipleErrors [MultipleErrors ... such thing has no sense.

Again, we're not the ones constructing these. And if Quasar does something silly and produces these kinds of errors we need to be able to handle them.
What we definitely need to do is to erase less information, so that we have the relevant information available when we present errors or suggestions to the user. (For example reducing every 404 into a nullary constructor needs to be changed. The backend uses the message body to communicate relevant information with us, see: https://github.com/slamdata/slamdata-backend/pull/241#discussion_r141148214
Which instance do you get by wrapping the QError datatype in a NonEmptyList that you couldn't use before?

I'm with @kRITZCREEK on this one - the representation not matching what Quasar gives us could be a bit of a problem, as it might well send us MultipleErrors inside MultipleErrors, etc. so trying to avoid that just gives us a new problem of having to somehow flatten that, but that would then lose the information that comes with the containing error.
I think the idea was we were going to work with the backend team to clean up the error representations anyway, and introduce tags and whatnot to make it easier to get semantic information about the errors that we get - so we may as well wait and see what comes of that before doing anything drastic to the representation here.

I'm still not too clear on what the motivation for this is either, aside from maybe a tech-debt-y kind of thing - I assume there was some specific thing that spawned the change rather than just wanting to clean it up a bit, since it's not that trivial a change.

If quasar can return MultipleErrors [ MultipleErrors [ then it can return MutltipleErrors [] too. 😞
This means that the only thing we can do is Foldable instance.

Basically I wanted foldable but MultipleError felt a bit weird and I noticed some slightly odd edge cases  so I thought it should probs be NEL instead. Foldable works just as well for the specific use case so lets close this.

What do you want to fold over? QError has the wrong kind for a Foldable instance.


OutputEvent objects should respect output severity

If category is stderr, then 'variables' is never called.

Looking at the code we do not use severity in a case for OutputEvent with a variablesReference. It is simply ignored.
For me to investigate further I would need exact repro steps

Sorry, I must have changed two things at once, because the actual problem I'm having is with this check event.body.output.length > 0. I think output shouldn't be required in this case, since it's ignored.

But the fact that severity is ignored is also an issue, right? I'll open a new issue for the output part.

I was hoping to use variablesReference for all output events, not just ones that contain objects, for consistency. If it's better to check the types that were logged and fall back on the original behavior for strings, I can do that. But I think it would be good if there could be an indicator that an object was logged as an error, or thrown. It should stand out if you're skimming the log.

@roblourens but what would happen if you log an object as an error. Only the top level object would get decorated as an error or all children would also get decorated as an error.
I am not seeing a huge value in adding this. Putting it to the backlog until there is a clear use case for this.

This seems really important to me. If you have an app producing lots of logs, exceptions and errors need to stand out. For node/chrome, I expect to use it for any console.error (at least with an object) or thrown exception. The first time someone misses an error because it's buried in identical logs, they will trust the console less. I'm not sure exactly what it should look like though.

Ok, let me assign back to me since you think it is important.
I suggest that we only decorate the parent object in a special way and once it is expanded the children are decorated regularly

@isidorn Are you still planning on this for the month? Let me know if I can help.

@roblourens yeah I actually planed to look into it tomorrow. You can help me by letting me know how would you expect this to behave. Is it fine if only the top level object is colored red and then all the children as usual? That would fix your concern of making it easier to spot in a lot of output
Here's a code pointer in case you feel like tackling it https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/debug/electron-browser/debugService.ts#L338 basically the severity should be passed and that object should have some property such that the repl viewer nicely decorates it in red

Cool, yeah what you describe is just how I'd expect it to behave. I may take a look, thanks.


[PORTAL] Deleting and Recreating a backplane show log from previous instance

Hello,
It seems that we see glitches in Azure Portal, when using an azure signalr backplane :

Create an Azure SignalR backplane
Use it for streaming
Delete it
Create  a blank new one with the same name/ region / resource group (not sure what how it matches)
DO NOT use it
go in Activity log in the portal

It will display logs from the previously existing instance.
It's a bit annoying in development when we tend to regenerate azure service on purpose, when trying to validate the ARM template to create our apps for example
For now, if we want clear logs, we have to generate "unique" name every time we re-generate it. So it also means we cannot pin it in the Dashboard
For example, this is an Azure Signalr that has just been create, and as we see it contains information from ~7h ago

It's by design. Azure Monitor(metrics and logs on Azure portal) recognize ResourceId (composed by subscriptionId, resource group name and resource name, which can be find under Properties) only and it is a common issue among all Azure resources.

thx a lot I had no idea that behavior
it's weird that the Id could be reused like that, it feel both logic and sooooo bad
the logs will ends up with tons of false positive
will probably open a ticket to the Monitor team to see if it could at least have a boolean to erase logs while deleting a resource


Data Virtual Fields

Virtual values should be cached automatically upon first creation. They should only change if the model values change.
Note: It's possible to read and parse the virtual field function, then identify any locally scoped attributes it depends on. These are the fields to monitor.
It should be possible to disable this feature so it always reruns the virtual field function.

Kamino closed and cloned this issue to ngnjs/NGN


fix: make introspection cache keys change when referenced files change

When calculating the cache key, try reading any string found as if it
was a file. If we succeed at reading it, add it to the hash. This
ensures any change to a referenced file is picked up when calculating
the key and all data is regenerated accordingly.

Thanks  👍


Handle optional multipart form content parameters

From here: https://github.com/Azure/autorest.csharp/pull/107

Awaiting multipart/form-data implementation: https://github.com/Azure/autorest.modelerfour/issues/28

Fixed as part of: https://github.com/Azure/autorest.csharp/pull/886


IO Mapping?

Is there an efficient way to implement a mapping action within the SPT framework?
Currently, I have STRUCT for each IO type with PLC inputs and outputs and create an instance of each STRUCT in the GVL for each physical IO device. For example, I can call my EL1008 on term 2 as term2.<E1..E8>. This lets me activate my configuration once and if I have to move my inputs around, I can do that with online changes by simply assigning my target variable to a different termN.~ variable.
This mapping action is something I can auto-generate in one location for easier commissioning. One thing I've noticed with declaring an interface and assigning it to a FB is that seeing input/output values is a little tricky when online on the XAE. Having this mapping action lays this all out?
Am I maybe missing something that makes this possible/easy? Do I just need to build my mapping as FB instances instead of STRUCTs?
AB#4765

Completely up to you.  We had discussed implementing a sort of I/O mapping scheme in conjunction with plans for an I/O diagnostics layer but that hasn't gone anywhere lately.


Set up continuous deployment

This aims at setting up continuous deployment in master branch for bench-routes. This is important in view of explanation to the public, testing of performance, behaviour, etc.

What platform would you suggest? @Harkishen-Singh

For now I think we should be going with heroku.


Implement timeout in SST and RDMC connection setup

Currently, nodes hang if they are waiting to receive out of band data to create RDMA connections for SST and RDMC. A failure of a node during this connection setup will lead to a violation of progress.
This has been discussed in detail before but we never got around to implementing timeouts.

As a matter of fact, I had to write connect-with-timeout methods for the TCP sockets in order to get the full-restart code working. You may find commit 5b5b3e5b5be6b1713f0d59cece163b98f915195b helpful.


Transactions doesn't validate the input for the resource

Hi,
I ran a transaction with a bunch of create requests.
The requested resources lacked the mandatory fields.
The transaction ran fine and created all the resources (without mandatory fields)
To me, it should have rejected the transaction.
Let me know if something is wrong in the request.

thanks,
Suresh

Hi Suresh,
By default the validator is not run on incoming requests or responses. You can enable validation by using the RequestValidatingInterceptor, per the instructions here: http://hapifhir.io/doc_rest_server_interceptor.html#RequestResponse_Validation

Hi James,
I integrated the changes as per the above documentation.
In the HAPI home page, I see the following error.
Unable to determine type of target resource.
thanks,
Suresh

Hi James,
I noticed that this happens if you have ResponseValidatingInterceptor. If you only have the request interceptor, looks like it runs fine.
thanks,
Suresh


Publish gem update to rubygems.org?

Hey,
Loving sunspot-queue, not loving how recent changes (in particular ReneB's compatibility restore aren't yet available on rubygems. Any chance you could publish a new version? Life get so much easier if gems are available in the default source.
Ta!

:+1: it would be great to see 3785398 in a release

@patrickatroli @lmars just pushed the changes to rubygems as 0.10.3. Thanks for pushing on this and sorry it's taken so long.

Thanks!


Insert NULL value

First, thanks again @internalfx for this awesome project.
I'm getting this error every time I sync my production DB,
It doesn't cause any problem but I'm curious as to where this is coming from:
Do I have a NULL document? Or Maybe a document with NULL as it's key?
If so how can I fetch it?

After looking at the code, I do not think I can fix this without a copy of the database that caused the error.
I should only need the anonymous_users table.
If there is personal data in there, perhaps you could anonymize the data by replacing some of the characters with *.

Thanks @internalfx, appreciate the willingness to help out 👍
The table doesn't have any sensitive data and it's anonymous.
I'm running the dump command. How would you like me to send it over? Dropbox perhaps?

A dropbox link will do nicely.
Thanks for reporting this.

You can email it to<EMAIL_ADDRESS>

@sagivf Just tried it and I was unable to replicate the issue!
I even tried going back a few versions.
Try grabbing the latest thinker v0.9.0 (just released). And let me know how it goes.

I updated and still getting it.
You say you tried syncing to a remote DB and it completed with no error?
I think we should leave this issue open to see if anyone has something similar and close it later, but what ever you prefer.

If that is the case. The only other variable I can think of is the RethinkDB version.
What version of Rethink are you running?

I'm using the RC1 that open-rethinkdb are working on (but I' might have seen that error before).
rethinkdb 2.3.6-0RC1-6-g458e57 (CLANG 5.1 (clang-503.0.40))
Perhaps you could try that out?

I will leave this open for now.
I assume you will be running a stable version someday. If the problem goes away I would like to know.

OK, I reinstalled 2.3.5 and it doesn't happen.
Do you think this is an issue with the RC? Or perhaps with thinkers computability with it. Worth letting people know I think.

We'll keep this open and see if the problem persists after the next version becomes stable.


Block edge 4.5.14

4.5.14 needs to be disabled:
2 clusters currently failing (14%),  1 gone ( 7%),and 10 successful (71%), out of 14 who attempted the update over 7d
Currently failing classification:
* API crashlooping: 1
* UPI router degraded: 1
* Untriaged: 1
* Version retarget: 1

4.5.14 can be enabled again:
1 clusters currently failing ( 7%),  3 gone (21%),and 10 successful (71%), out of 14 who attempted the update over 7d
Currently failing classification:
* API crashlooping: 1
* UPI router degraded: 1
* Version retarget: 1


nebula-operator中没有处理service里面的annotations，没办法增加自定义的label到service的annotations里面

@woaiwah
Emm, thanks for your feedback, there is indeed no assignment here. Can you try to help submit a pr?
https://github.com/vesoft-inc/nebula-operator/blob/master/apis/apps/v1alpha1/nebulacluster_common.go#L413-L421

@veezhang
So sorry！I don't know much about go language. I hope you can help solve this problem

@veezhang Line 383, func generateService(c NebulaClusterComponentter) *corev1.Service

@woaiwah
Thanks, we're going to fix it.
If you are in a hurry,  you can create a new service and then set annotations to it . Not sure if this can help you?

@woaiwah
What are you setting annotations for? I'll see if I can help you.

The internal k8s cluster of our company is managed by the operation and maintenance department. When I use k8s cluster deployment，I need to add a customized annotation of the operation and maintenance department, so as to comply with their rules. So i need to setting annotations in service

@woaiwah Emm, you must set the annotations for all the service ?

@woaiwah Emm, you must set the annotations for all the service ?

Yes，deployment nebula-cluster，only graphd-svc needs

@woaiwah Can you add an new service xxx-graphd-svc-new with the annotations?

similar to exposing, making it accessible to the outside kubernetes

Yes , you are right，Now I'm try to add an new service nebula-graphd-svc-new with the annotations, I  don't know if I can succeed，This way will make graphd have two service。 Let me try。

similar to exposing, making it accessible to the outside kubernetes

Yes , you are right，Now I'm try to add an new service nebula-graphd-svc-new with the annotations, I don't know if I can succeed，This way will make graphd have two service。 Let me try。
@woaiwah
Emm, Two Services are fully allowed. You can try it out and contact us if you need support.

You can try it out and contact us if you need support
Follow the above method，Two Services，and It can be used normally

Follow the above method，Two Services，and It can be used normally

Follow the above method，Two Services，and It can be used normally


Wayfair integration

Integrate wayfair including:

Listings one-way
Orders
Price and Inventory setting
Inventory (Castlegate) management

order test completed.
inventory test in progress


Ideas for LitElement 3.0

LitElement 2.x has been out for about a year, and we’ve been considering what changes we should make for the next major version. We wanted to share our thoughts and get feedback from our users about potential improvements and breaking changes.
Overall, we’re generally pretty satisfied with the core functionality and API and we definitely want to keep in mind that dealing with breaking changes is a hassle for users. We do, however, think there are some good opportunities for improvement. The lit-html library is also considering changes for the next major version, and we’ll definitely be including the next version of lit-html with the next version of LitElement.
Goals
Backwards compatibility for most users
We know that dealing with breaking changes is annoying and we’re trying to carefully manage our change budget such that each change has either a big return on investment or is likely to affect very few users. If necessary, we may elect to create a compatibility version that maintains 2.x behavior if it makes sense.
Performance
We love performance and are always striving to improve it. The next version of lit-html has a number of performance improvements from which LitElement will naturally benefit.
Size reductions
There’s some good opportunity for improvement in the core size of LitElement. First, the next version of lit-html should be getting a good bit smaller. Then, there’s a good bit of refactoring we can do to help make sure users are only getting the code that they use, including making old browser support opt-in, making decorators opt-in and more granular, and streamlining some of our internal API.
In addition, we may publish a minified, bundled build so that we can ensure that a heavily minified version works correctly. While we believe minification is ideally an app concern, we realize that apps won't know all the transforms that can be safely applied to our code.
Developer Experience
We want to make sure LitElement is easy to use for all our users. We know that some web devs love the pure experience of downloading some code, editing in a text editor, and seeing the output in a browser and we want to make sure that we support that use case better.
We would like to improve error messages, and not let publishing minified code negatively impact development. We'll look into producing both production and development builds.
Easier SSR
We know users want SSR, both for SEO and first paint performance. By leveraging the support for SSR being built into the next version of lit-html, LitElement will support SSR and it will be able to take advantage of the declarative Shadow DOM feature being added to Chrome.
New Features
While we want to consider some feature additions, we’re pretty happy with the core functionality. One thing we’d like to explore is providing a package of helpers for features not everyone needs but are really helpful for specific use cases or are just one way to skin the cat.
Fix bugs that require minor breaking changes
We have a number of longstanding minor issues that we haven’t been able to fix because they are just slightly breaking changes. We’d like to evaluate those and address what we can.
API cleanup
We think there’s a number of opportunities to reduce code size by carefully sweeping through the API. This should mostly be internal changes, but there may be some minor changes to the public facing API where we think there’s a strong benefit.
Potential Changes
Opt-in polyfill support
Although the Shady DOM polyfill itself is opt-in, there is some code baked into LitElement to use the polyfill that all users must pay for, which adds close to 1KB (~15%) to the bundle size. We’d like to make this opt-in so users who don’t need to support older browsers don’t pay the cost of downloading the polyfill specific code.
Opt-in and granular decorators
LitElement's main module exports all of the decorators we support regardless of whether or not they are used. We will break these out into granular modules that users will import if they use. This will also allow us to more freely add new decorators where useful.
Package that works out of the box without building
For optimal code size a build will always be best, but we want to provide an easy way to try LitElement without using npm and building the code.
Guidance for use in popular frameworks
The main value proposition of web components is that they work everywhere the (modern) web works. That’s true but they should also work seamlessly with modern web frameworks as well.  We want to make sure LitElements work great in popular frameworks like React, Vue, and Angular. As shown on custom elements everywhere, the situation today is pretty good, and we may only need to create a set of examples showing what’s possible. However, we will be considering patterns and helpers that can make things easier for framework users.
Code sharing primitive
We think that subclassing and mixins cover most of the cases where users want to share code between elements. However, there are some cases they don’t cover. We’ve been impressed by efforts in the community to address those use cases, in particular React Hooks and the Vue composition API. We think there’s an opportunity to do something similar but probably a lot simpler for LitElement. This might take the form of controllers that can bundle functionality via a has-a relationship with the element and that can interact with the lifecycle of LitElement. Since not everyone needs this feature, this is probably a good candidate for a helper package.
SSR Support
When SSR output is being generated we need to consider which parts of the element lifecycle to run. It’s a goal of our SSR implementation not to require a server side DOM implementation and therefore code that uses DOM APIs will have no or very limited support. We will likely be modifying the update cycle for the element when it’s run on the server to avoid methods which often perform DOM manipulation, for example the firstUpdated and updated methods.
Theming
Platform support for theming is still incomplete. CSS custom properties are great for tree-based theming of known sets of properties. The new ::part selector works well for arbitrary theming of specific elements. However, the exportparts attribute is a cumbersome way to expose parts up the tree. In addition, it’s often desirable to allow users to style a set of unknown properties but not everything. There are a lot of patterns that can help here and we may end up supporting a few of them, perhaps in a helper package. We like the Vaadin themable-mixin and something like that for LitElement may make sense. We also like the power and configurability of Sass mixins and may explore exposing something similar via a Javascript API.
Declarative events
Declaring what events your element fires is great for self-documenting. We can also follow the DOM convention of providing an on prefixed property to listen to the event. Having on prefixed properties also improves integration with frameworks like React that configure events this way. We will probably implement this as a decorator but will have some form of raw JS support as well. See this issue for more info.
Common customization like shadowRoot rendering
To customize how the element’s shadowRoot is created you currently have to override createRenderRoot. We’d like to make this a bit easier and may add a decorator or static field with which you can supply the options object to attachShadow. For example:
static shadowRootOptions = {mode: ‘open’, delegatesFocus: true}
We may also explore this for other common but simple to configure customization points.
Declarative host manipulation
While we use lit-html to render the element’s Shadow DOM, attributes and event listeners on the hosting element itself must be added imperatively. We may be able to use some of the new features in lit-html 2.x to create a declarative way of doing this. This might take the form of a renderHost method which returns a lit-html TemplateResult that’s rendered on the host element. See this issue for more info.
Update coordination
LitElement updates asynchronously at microtask timing, and while this can’t be observed by the user, it can be by code. After an element has been interacted with, it’s sometimes useful to know when it’s finished rendering; for example, this is useful in testing, when firing events, or when you need to know the element’s rendering is stable. Although this can also be used for measuring DOM, it’s usually better to measure in a requestAnimationFrame callback. LitElement provides the updateComplete promise for these use cases. However, this only covers the element itself and not any LitElements in its shadowRoot. To wait for those elements, typically you override the updateComplete property and await those elements as well. That’s a bit cumbersome, and we want to explore adding a helper that makes this easier. Since this is only sometimes needed, this might be another feature which gets added to a helper package.

Excited for this. A couple things that came to my mind:

Maybe https://github.com/Polymer/lit-element/issues/469 can be revisited? It is no longer much of an issue for us, because we nowadays mostly use the updated callback, but I still find the issue I raised there to be worthwhile fixing and now might be the time.
Using updated extensively, I like it, but I feel some of the user experience could be improved:

If someone renames a property they also have to rename all the occurences of that property in updated. Worse even there would be no (compile) error, so this would only ever be noticed when the component is in use or testing.
It would be nice to have this typed too.
I do not know how to make this happen I am afraid, but maybe there is something Typescript can provide here.

Maybe the docs could provide some additional information on bindings and how to handle rerendering. Sometimes we encounter an issue that a property changes within a component and then the component gets rerendered and the state is lost. I would love some more info on when this happens, how this happens and how to best deal with it.

Oooo, lots of good stuff to chew on here… I'm particularly interested in the "Code sharing primitive" angle, as it something I was thinking about recently as well. I did a lot of StimulusJS work before becoming enamored with LitElement,￼ and one advantage Stimulus has is you can attach multiple controllers to a single element. It would be cool if I could explore an analogous pattern in the LitElement world…

@Christian24 #469 is already addressed in 3.0. requestUpdate() does not return a Promise anymore, and you have to specifically call await this.updateComplete.

may we have good documentation on bundling large apps, and coding exercises / challenges.

A functional approach such as react hooks would really be nice.

may we have good documentation on bundling large apps, and coding exercises / challenges.

I think that's already taken care of by open-wc?

How early do you think we could start to see tech specs on the controller proposal mentioned herein? It sounds like a great tool for empowering both early LitElement learning as well as advanced/shared application development. I’d love to see whether you’d see it deeply integrated with LitElement, a pair to lit-html, or something more abstractly applicable to UI development at large.

@funglaub

A functional approach such as react hooks would really be nice.

We feel that we already have a pretty functional approach with the render() method of LitElement.
There's a lot of dislike of classes out there, but for this case where we 1) are creating objects by nature of the DOM and 2) do need to declare properties and attributes, classes are actually more declarative than a "pure" functional API where attributes and properties must be declared without the advantage of native syntax for it.

@Westbrook

How early do you think we could start to see tech specs on the controller proposal mentioned herein?

I'll try to publish an issue today.

Exciting ! :)
On Fri, Sep 11, 2020, 11:28 AM Justin Fagnani<EMAIL_ADDRESS>wrote:

@Westbrook https://github.com/Westbrook
How early do you think we could start to see tech specs on the controller
proposal mentioned herein?
I'll try to publish an issue today.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Polymer/lit-element/issues/1077#issuecomment-691162521,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFSDL2W6OPJSKVVVSCGAXI3SFI62JANCNFSM4RDTWGKQ
.

@Westbrook https://github.com/Polymer/lit-html/pull/1246

I really like LitElement, so thank you in advance!
I think it would be awesome to see like a showcase of who else/what companies are also using it as this would be great publicity and help advocate its usage in organisations.
I think more demos/starter kits, already mentioned is how to use it with other frameworks but I think examples of large applications/advanced usage would be great and also starter kits that can generate the boilerplate for standard usages e.g. with an app shell, routing, linting, testing etc. Would be happy to contribute to these!

Make it compile. Like Svelte, solit-js

@kmmbvnr

Replace html templates with compiled js. Like Svelte and solid-js

Any reason why?

@justinfagnani

Any reason why?

Performance ?

It would be great to get support for <slot> or an equivalent for the light dom. If I'm not mistaken, Stencil supports this. The thing is, you don't always need or want shadow dom, but the concept of slots is still very handy.

It could be nice to streamline this kind of pattern with decorator options
class WaitsForChildren extends LitElement {
  render() {
    return html`
      <x-l id="a"></x-l>
      <x-l id="b"></x-l>
    `;
  }

  async _getUpdateComplete() {
    await super._getUpdateComplete();
    await Promise.all(Array.from(this.shadowRoot.querySelectorAll('x-l'), x => x.updateComplete);
  }
}

class WaitsForChildren extends LitElement {
  @query('#a', { awaitUpdate: true }) a: XL;
  @query('#b', { awaitUpdate: true }) b: XL;
  render() {
    return html`
      <x-l id="a"></x-l>
      <x-l id="b"></x-l>
    `;
  }
}

class CustomInput extends LitMixin(HTMLInputElement) { ... }

// or

@builtIn(HTMLInputElement)
class CustomInput extends LitElement { ... }

// or any other solution to reconstruct the prototype chain

One thing I've been running into a bunch lately is when I have a Lit component that requires me to know my own component bounds as part of the render (I'm absolutely positioning elements), there's no great update mechanism. In fact it was kind of terrible previously, but at least now I can listen to ResizeObserver. It might be nice to have some set of bindable properties that the user doesn't change, but they can opt into that trigger requestUpdate.
For example:
@property({ type: Number, internal: 'bounds.width })     protected componentWidth: number;
Bounds of course would be from this.getBoundingClientRect.
I'm not married to the my implementation suggestion by any means, but all the same, if it was similarly implemented, it could open the door to anything that you might add-on here if there was an API to do so (timers, sensors, data request results, etc)
Honestly, this type of functionality probably doesn't have to be part of Lit, but I'm kinda sick of re-writing ways to handle this. So if not Lit core, some kind of companion util might nice

@bengfarrell I think this might be nicely addressed with what I've been calling recently "reactive controllers" - helper objects that are able to hook and trigger the host element's lifecycle.
Imagine a controller called BoundsController which installs a ResizeObserver and on resize pulls the bounding rect and triggers an update. It'd be useable like:
class MyElement extends LitElement {
  private _bounds = new BoundsController(this);

  render() {
    return html`<pre>width: ${this._bounds.width}, height: ${this._bounds.height}</pre>`
  }
}

Note, this is pretty easily writable today - it doesn't require any new APIs on LitElement.

@justinfagnani I think that's exactly the type of thing I was steering towards if I put more thought into it. And yes, it IS easily writeable today, but as a user the design pattern didn't really occur to me until I thought about what I was missing. And this is why I'm wondering if a few reactive controllers could be shipped alongside Lit (just import when you need it, not part of the core lib), in the same way you're offering extra directives. The few that ship could solve some common problems like bounds, but more importantly offer guidance to create your own. Of course, this might fall under the category of "too opinionated" a design pattern to ship with Lit

@justinfagnani CustomElements spec allow you to register a component only once which is very much sensible but it would be great if the decorator @customElement('my-element') can skip declaration if it is already in the registry instead of failing with an error.
Currently I am doing customElements.get('my-element') || customElements.define('my-element', MyElement); to support this.
This is relevant because I use storybook for demoing and strangely, when you include same components in multiple different stories, they get registered multiple times throwing errors in the storybook.
A similar issue in a diffent context was raised here I guess: https://github.com/Polymer/lit-element/issues/207

Another thing which may not be relevant to this context is that, while everything is awesome, VSCode support is limiting. There are 1 or 2 extensions but they don't support everything like css language support within the css tags (or am I doing something wrong?)

Also, there is no syntax highlighting in this case 😢
Infact, I am even wondering if it is recommended to put the .css file separately or write css within the css tags.
PS: The <style> tag within html works well though but I just use html tag for html and css tag for css

Also, for people who are starting off something which you guys did like PWA helpers (https://github.com/Polymer/pwa-helpers) for lit would be great. While open-wc has https://open-wc.org/developing/lit-helpers.html it may either need more additions to it or you may want to take it up. For eg. the recommended way to do routing (with each element handling its own routing) would be great. But, this is not a must have and not related to lit 3.0 either, just a suggestion.

@tvvignesh

@customElement('my-element') can skip declaration if it is already in the registry instead of failing with an error.

We'd rather rely on a standard solution to this like Scoped CustomElementRegistry. Protecting against this exception can mask true errors in a program. We don't think that first-to-register is a reliable way to handle conflicts.
I also wouldn't want to make @customElement harder to explain. There's a big benefit to saying that it's just a declarative form of customElements.define() and behaves the same.
Re: VS Code plugins, I get CSS highlighting with lit-plugin: https://marketplace.visualstudio.com/items?itemName=runem.lit-plugin I'm not sure what's happening for you, but I'd use that or file an issue if you already are.
Re: App recommendations. We're definitely looking into addressing these topics directly in docs. I'm not sure we'll call them recommendations or not, but we do want to guide developers towards answers for common needs like routing.

Hello all !
Some really great stuff going on in here - I wanted to post a snippet of some code which aims to give inspiration as to how we use controllers and lit-element within Runtime.dev today in our products - which is built on the component controller model as well as on top of LitElement. I also wanted to share some thoughts on the aforementioned topics!
Runtime.dev's component lib is built on a component controller model and seeks to achieve some of the things that are being noted here, Injectable styles, differential rendering, separation of state/logic and markup, both DOM and JS event dispatching & execution management, graph-linked/connected controllers, dynamic accessibility & focus management through controllers, etc. The list goes on.

protected description = {
        // Icon Controller Used in coordination with the input's validation state
        icon: new IconController({
            // Initial Icon SVGTemplate
            svg: CIRCLE_ICON,
            // Standardized rem sizing - can use IconSizeEnum.INHERIT to style externally
            size: IconSizeEnum.SMALL,
            accessible: true,
            aria: {
                label: 'Description Completed Icon',
                role: AriaRoleEnum.PRESENTATION
            }
        }),
        input: new InputController({
            // Differential Theme
            theme: DefaultTheme,
            // Initial States of input validation
            valid: false,
            // Fully async Validation Function
            validate: async ({ value }) => {
                const valid = Boolean(value);
                // Updating icon of other controllers when validated state changes
                this.description.icon.svg = valid ? CHECK_ICON : CIRCLE_ICON;
                return {
                    valid,
                    error: {
                        message: '',
                        caught: false
                    }
                }
            },
            placeholder: 'A description also...',
            // Injectable templates that get injected into shadowRoot as opposed to slots
            trailTemplateFn: ({ valid }) => html`<runtime-icon .controller=${this.description.icon} class=${valid ? 'valid' : 'invalid'}></runtime-icon>`,
            // Injectable Styles which apply to injected content
            styles: [css`
                runtime-icon.invalid {
                    ${svgPrimaryColorLightest};
                }

                .valid {
                    ${svgPrimaryColor};
                }
            `],
            //JS Tied in event callback
            engagedCb: async (e) => console.log(e)
        }),
    };

    get details() {
        const { information: { card, descriptor }, name, description, } = this;
        //Inject all controllers into markup
        //Components handle Animation, Interaction, Layout, and Styles
        return html`
            <runtime-card marginTop mdPadding .controller=${card}>
                <runtime-vertical-layout startAligned id="details">
                    <runtime-text .controller=${descriptor}></runtime-text>
                    <runtime-input marginTop .controller=${name.input}></runtime-input>
                    <runtime-input marginTop .controller=${description.input}></runtime-input>
                </runtime-vertical-layout>
            </runtime-card>
        `;
    };

Obviously Runtime.dev takes this model to an extreme and is several generations in but I think that the direction of LitElement/HTML 3.0 through a component-controller model is a great evolution.
A few things to note IMO:

The Hybrid Approach of drop-in controllers (Runtime V1 did this), it's too flexible and doesn't scale well. We moved to an entirely controlled structure where if a component supports a controller - it is dependent on that controller. Otherwise it's considered a dumb component and is primarily visual/structural. Additionally all components have one controller that encapsulates a subset of functionality.

Sizing best to be managed externally we have Positioning Engines and Virtualization Engines Dedicated to this - as opposed to being handled internally. Adding a resize observer and then running getBoundingClientRect may drill perf especially if you use it like this often. Also - developed systems being to want to understand how things are sized in relation to each other and how things may render in context of other things rendering around them, this is particularly important for virtualization, masonry layouts, and grids. (Virtualization of Google Photos)

Waiting on children to update/render is also easily implemented if all of your children have controllers as opposed to some of them however - if only some children have controllers and others don't then this introduces inconsistencies/uniformity problems. I would suggest this type of thing to be implemented on the component level as opposed to through a controller infrastructure. The same thing applies to focus management. It works out best if everything that is focusable is also controlled.

I would suggest that elements take in only one controller and that controller is explicit in its capabilities so that the expectations of what is available (Sizing, Theming, Updates, Etc.) becomes standard almost as we expect things such as connectedCallback and attributesChangedCallback within native WC. Treating controllers as directives is something that I would recommend avoiding - the extension based controller system has worked out very well for us: note in the image below our InputController extends an InteractiveController. Which guarantees particular behaviors and functionality as opposed to having to remember if a component has x/y/z controllers such as theming/bounds/etc. This also makes it easier to build systems that manage groups of controllers such as focus engines, placement engines, and state engines.

If you want to get a sense of of this direction and how it impacts WC applications at scale take a look at these:
Component Controller Model & LitElement
Component Controller Model At Scale Google Slides
Talk for Slides
Nevertheless - a bit of a shotgun thought process here due to controllers simply opening the floodgates on possibilities. Our lit-element WC have been controlled for about a year now and we have learned a lot. I would love to see a community perspective on this as it may impact how we move into the future and perhaps how we can help you avoid the madness we ran into here and there.
Would be happy to have a live chat/meet and go over a couple of these things/answer some questions. Runtime isn't open sourced yet - we are developing our public License right and scoping public demand for such a thing.
It is however actively being Licensed to our partners and we are under serval NDAs with Google, Microsoft, and others so I am available to guide/brainstorm pretty extensively without getting in trouble.
We are currently focused on building an upcoming product but we are always improving Runtime and we would love help bringing it into the community in conjunction with LitElement 3.0
I also read the PR's and Issues for LitElement and LitHTML daily and so I am very informed and happy to give my perspective on design choices being made and why we did or didn't do something similar.
Feel free to reach out personally at<EMAIL_ADDRESS>or @KnottTsavo on twitter.
Sorry for the typo's I'm on the run today!
Anyway - have a great day and happy coding!
All the best,
-Tsavo

@tvvignesh

@customElement('my-element') can skip declaration if it is already in the registry instead of failing with an error.

We'd rather rely on a standard solution to this like Scoped CustomElementRegistry. Protecting against this exception can mask true errors in a program. We don't think that first-to-register is a reliable way to handle conflicts.
I also wouldn't want to make @customElement harder to explain. There's a big benefit to saying that it's just a declarative form of customElements.define() and behaves the same.
Re: VS Code plugins, I get CSS highlighting with lit-plugin: https://marketplace.visualstudio.com/items?itemName=runem.lit-plugin I'm not sure what's happening for you, but I'd use that or file an issue if you already are.
Re: App recommendations. We're definitely looking into addressing these topics directly in docs. I'm not sure we'll call them recommendations or not, but we do want to guide developers towards answers for common needs like routing.

@justinfagnani Thanks for your hint regarding the extension. Switching to the extension you had suggested worked great (able to get syntax highlighting and autocomplete for everything now 😃) I was using https://marketplace.visualstudio.com/items?itemName=bierner.lit-html before which has huge number of downloads.

Regarding scoped custom element registry, I read about the discussion you had initiated here: https://github.com/w3c/webcomponents/issues/716 and your gist here: https://gist.github.com/justinfagnani/d67d5a5175ec220e1f3768ec67a056bc . Looks like it has been 3 years since it started. Would it get implemented? 🤔 And even if it does at some point, I guess it would take ages for all the users to get the updates with all the browser vendors taking their own time to support it 😟 Anyways, I guess I have to go with my hack till then.
Btw, on a side note I remember this talk back when Polymer was the thing: https://www.youtube.com/watch?v=tNulrEbTQf8
Does Youtube still use Polymer or has it migrated to Lit? Any reference architecture we can get from there would be great. Currently I am sticking to the Open-wc recommendations but some real world prod reference would be great to have.

Switching to the extension you had suggested worked great (able to get syntax highlighting and autocomplete for everything now 😃

I miss code collapse support: https://github.com/runem/lit-analyzer/issues/31
I really like LitElement but tooling support is way behind other libraries like React, Vue

Switching to the extension you had suggested worked great (able to get syntax highlighting and autocomplete for everything now 😃

I miss code collapse support: runem/lit-analyzer#31
I really like LitElement but tooling support is way behind other libraries like React, Vue

Yup. I completely agree with you. Lit is great for the most part with all the features it currently has. So, instead of bloating it or changing things up a lot, its more important to put the investment to efforts like what Open-wc (Now modern-web) is doing, emphasising more on the performance and maybe create helpers, tooling and focus more on efforts towards things like this: https://github.com/material-components/material-components-web-components which can be a boon for not just people using Lit but also for people coming from other frameworks.

@tvvignesh
I agree that Lit* (in fact web components) needs improves its ecosystem with e.g. more mature feature rich UI libraries / design systems but in my opinion performance is pretty good as is.
Developer experience should be priority (it's already good but things like missing code collapse in IDE gets in my way from time to time)

@tvvignesh
I agree that Lit* (in fact web components) needs improves its ecosystem with e.g. more mature feature rich UI libraries / design systems but in my opinion performance is pretty good as is.
Developer experience should be priority (it's already good but things like missing code collapse in IDE gets in my way from time to time)

DId you try setting "editor.foldingStrategy": "indentation" as mentioned there. It worked for me.

DId you try setting "editor.foldingStrategy": "indentation" as mentioned there. It worked for me.

No. See my comment there.
Thats just like i said above: from time to time issues in lit-* tooling requires me to think about it, look for workarounds etc. In a mature ecosystem this does not occurs

@bengfarrell I think this might be nicely addressed with what I've been calling recently "reactive controllers" - helper objects that are able to hook and trigger the host element's lifecycle.
Imagine a controller called BoundsController which installs a ResizeObserver and on resize pulls the bounding rect and triggers an update.

Why not go all the way and also trigger life-cycle events from data change observations, like in MVVM? That could replace property change observations and allow for a pluggable way of triggering updates.

I would also like to throw revisiting #812 in the mix. The issue is about using ES2015 proxies to support reacting to changes to an object property or an element in an array. Currently such assignments are not recognized and need workarounds leading to confusion for some of my colleagues and errors.
Vue 3 is implementing the same feature and as shown by the last comment the implementation is fairly simple. As the next version of lit-html is not going to include IE11 support in the core library I think this is a good time to implement this.

Make custom elements compatible with native elements

@septatrix lit-mobx already does a great job of that: https://github.com/adobe/lit-mobx It's very similar to Vue 3's reactivity library. There's a number of different way that LitElement authors are handling state change tracking, from MobX to Redux, to events + immutable data. I don't think we want to chose a particular way, but enable many of them. Being able to hook update() and call requestUpdate() are powerful primitives for these libraries to use.

@busynest I'm not sure what you mean

@justinfagnani With a proxy based observable approach one can replace a big part of lit-element's property tracking. A nice library to use for that is https://github.com/nx-js/observer-util.
I have done exactly that with https://github.com/kwaclaw/KdSoft.lit-mvvm.

I also see this as a superseeding of the current approach. Proxies allow a greater control and are able to react to more changes. Furthermore implementing this natively could be done in only a few lines and not add the weight of a comparatively huge dependency lige mobx, redux etc.

My biggest problem was always that the I couldn't just develop with it because of the module specifiers.  In the end the solution I had to use was to use rollup at npm install time to copy to a client/libs directory (most of my apps each has a common node_modules and separate server and client directories).  I like that you are considering the out of the box ready to use - but please note that node_modules isn't always located at the root of the client directory.
Other than that lit-html, lit-element and webcomponents loader is all I've needed (other than my own utilities) (I don't build, my production systems don't seem to need it - not even minified anything).

@akc42 I am using Snowpack for the same purpose.

Nice work, excited about "Declarative Events"!

Be able to pass an @query to another child element.
Currently if I need to pass a sibling to another child element I would do something like this:
@query('foo-element') foo!:FooElement;

render() {
  return html`
    <foo-element></foo-element>
    <other-element .foo=${this.foo}></other-element>
  `;
}

However that will not work on first render since  isn't in the dom yet and the query will fail. So currently you have to work around this by waiting for first update and then querying and then manually passing to the other child. It would be great if there was some mechanism that the property could automatically be resolved without rendering twice or reverting to some imperative programming.

Typed PropertyValues would be really clutch. For static properties getter, I'm sure it could be inferred. not sure about decorators, though.
@property() newPropName: string;

updated(changed: PropertyValues) {
  if (changed.has('oldPropName')
    whoops();
}

I would love to see a considered answer to the question, "what does it mean to render without a shadow root?"
In practice, one does not always need to create a shadow root in order to have a useful component implementation. There are a handful of cases today where it would be better not to use a shadow root.

A11y may take priority over style encapsulation
SSR may be desired without the complexity of emulating declarative shadow roots
I may wish to render a top-level document that is more complex than a single application element

LitElement as of 2.x makes rigid assumptions (as a matter of internal implementation) regarding the usage of a shadow root. This suggests to users that although it may be possible to create components without a shadow root, it is not the intended usage of LitElement. This in turn interrupts the exploration and adoption of novel, higher-order usages of LitElement.
It is not necessary for LitElement to establish a first-class workflow for components that do not use shadow roots. However, the LitElement base class should become a viable candidate for such a workflow, one that does not levy a cognitive or performance tax on authors who seek to use it that way.

Idea for lit-labs package: consider implementing a portal directive which could serve for building modals, tooltips etc.
Right now pretty much every more or less complex web components library has its own mechanism. At Vaadin, we use vaadin-overlay which teleports elements under document body. Other alternatives include scanning DOM tree to manage z-index.
It would be nice to have a recommended approach. There used to be iron-overlay prototype under PolymerLabs but it hasn't been finished.

https://github.com/Polymer/lit-element/issues/1077#issuecomment-694749771

Does Youtube still use Polymer or has it migrated to Lit?

(totally off topic lol) Yikes. YouTube still uses Polymer?! No wonder its so slow /s. I had been using an extension to use the old YouTube until YouTube broke it earlier this year. :(((
um. yay opt-in polyfills. ie needs to die.

Any nice solution to solve unistore binding to LitElement.

https://github.com/developit/unistore/issues/175
https://github.com/developit/unistore/tree/master/src/integrations

My not ideal solution...
export const connect = store => superclass =>
  class extends superclass {
    static get properties() {
      return {
        // The observedState contains selected the store state props by observedStateProps var.
        // Any change of observedState will be run render() of LitElement.
        observedState: { type: Object },
      };
    }

    constructor() {
      super();
      this.observedState = {};
      this.observedStateProps = [];
      this._stateChanged = this._stateChanged.bind(this);
    }

    connectedCallback() {
      if (super.connectedCallback) super.connectedCallback();

      store.subscribe(this._stateChanged);
      this._stateChanged(store.getState());
    }

    disconnectedCallback() {
      store.unsubscribe(this._stateChanged);

      if (super.disconnectedCallback) super.disconnectedCallback();
    }

    // The `_stateChanged(state)` method will be called when the state is updated.
    _stateChanged(state) {
      const observedState = {};

      this.observedStateProps.forEach(prop => {
        observedState[prop] = state[prop];
      });

      if (
        Object.keys(observedState).length &&
        !equals(this.observedState, observedState)
      )
        this.observedState = observedState;

      this.stateChanged(state);
    }

    // eslint-disable-next-line class-methods-use-this
    stateChanged() {}
  };

Inspired by

https://github.com/Polymer/pwa-helpers/blob/master/src/connect-mixin.ts
https://github.com/GoogleChrome/web.dev/blob/master/src/lib/components/BaseStateElement/index.js

(apologies, as this is somewhat off-topic)
@JosefJezek I have experimented with Unistore-like patterns on top of LitElement. I have a very radioactive / not-well-documented repo with my experiments here: https://github.com/cdata/bag-of-tricks
Usage ends up looking like this:
// A store:

const store = new Store<FooState>({
  bar: 'baz'
});

// An action creator that operates on the store:

const setBar = (bar: string): Action<FooState> => (getState, dispatch) => {
  return {
    ...getState(),
    bar
  };
};

// A connected component:

@customElement('foo-component')
export class FooComponent extends connect<FooState>()(LitElement) {
  @property({ type: String })
  @selector<FooState>((state) => state.bar)
  bar: string?;

  #setBar = selfDispatch(setBar);

  render() {
    return html`
<button @click="${() => this.#setBar('zot')}">Set bar to zot</button>
    `;
  }
}

// Meanwhile, in some entrypoint:

provide(self, store);

Some details about the above example:

Store extends EventTarget, and state changes are announced with dispatchEvent
A connect mixin creates a "connected" component without coupling it to a specific Store
selfDispatch is a helper that takes any action creator and returns a self-dispatching one (e.g., it automatically invokes store.dispatch(...) on the currently connected Store when invoked)
The provide helper takes any EventTarget and sets it up to provide connected components with the designated store as they are attached down-tree
The @selector decorator binds state in the store to properties on the component

The thing I like about this approach is that it neatly decouples the store from the component, which makes testing a lot simpler. In the course of a test, we can trivially substitute different stores without changing the implementation of a component (or trying to come up with some kind of fancy module substitution for its dependencies).
Anyway, feel free to borrow any of those ideas. I would be happy to talk about it more in an issue thread in that repo, if it interests you.

@justinfagnani Great things are being proposed here, I only wanted to ask you to keep LitElement free from to much "sugar code" and keep LitElement standards, I personally choose LitElement because is near to the platform and it doesn't look like Angular or React or any other Framework/Library...

right now LitElement does so magical merging of properties... which means that if you do
static get properties() {
   return {
     ...super.properties,
     newProperty: { type: String },
  }
}

there are some things that seem to have "bad side effects" (at least for us if we do this a lot of tests fails)
Could we get rid of this "magical merging" in LitElement 3?

@daKmoR I think that would stretch the breaking change budget, as it would break all subclasses of superclasses with properties.
UpdatingElement's property declaration merging is designed to mirror class inheritance so there's as close of a match in behavior between properties block and decorated class fields. With class fields you only have to define the class's own field and you automatically inherit the superclass's fields.
Why are you trying to spread super properties? Is something not working with the built-in inheritance?

@justinfagnani we would like to use typescript but not decorators.
And if you do not do ...super.properties then typescript rightfully complains
consider this example (also live on webcomponents.dev):
import { LitElement, html, css, CSSResult, TemplateResult } from "lit-element";

export class MyElement extends LitElement {
  static get properties() {
    return {
      greet: { type: String },
    };
  }

  greet = "nobody";

  protected render(): TemplateResult {
    return html`<p>Hello <strong>${this.greet}</strong>!</p> `;
  }

  static get styles(): CSSResult {
    return css`
      :host {
        display: block;
      }
    `;
  }
}

export class SweetElement extends MyElement {
  static get properties() {
    return {
      ...super.properties, // without this TS complains
      nice: { type: String },
    };
  }

  nice = "sweet";

  protected render(): TemplateResult {
    return html`<p>Hello <em>${this.nice}</em> ${this.greet} 🤗</p> `;
  }
}

customElements.define("my-element", MyElement);
customElements.define("my-sweet-element", SweetElement);

so if this ...super.properties is supposed to work (for us it does not - while it does in simple examples) then we could consider it a bug and I can look into making a reduced example on how ...super.properties breaks our code...
PS: we did not raise an issue before as we assumed ...super.properties is not supposed to work 🙈

...super.properties is not the intended use of the static properties declaration. Whether or not it works, I can't say because we don't test it. I don't particularly think we should make it work, but it goes against the design of the properties declaration, which is supposed to stay close to class fields.
What error happens if you remove the spread? I can't edit the webcomponents.dev example.
I think we need a separate issue for this.

you can click on "fork" (top right) and then you can edit
I saved a fork where it's removed
https://webcomponents.dev/edit/kMzS6JOhPAPsEHtV4zK5
and I get this

so unless there is an easy answer on how to solve this then yes a dedicated issue makes sense 🤗

another topic
when writing mixins for LitElement it is somewhat confusing how to merge styles.
I would assume a simple array merge should work
static get styles() {
  return [
    ...super.styles,
    css` // my styles `
  ]
}

it however fails if the element the mixin is applied to is doing
static get styles() {
  return css` // parent styles `;
}

I started writing merges like this 😭
    static get styles() {
      let parentStyles = [];
      if (Array.isArray(super.styles)) {
         parentStyles = super.styles;
      } else if (super.styles) {
        parentStyles = [super.styles];
      }
      return [
        ...parentStyles,
        css`

PS: I know that you could use super.styles ? super.styles : [], because of some flattening magic of LitElement... however I could not remember this magic and honestly a "no magic" array merge seems just simpler... as it won't need to be teached
Suggestion
LitElement should always require an array for static get styles.

Let's move the static properties discussion here: https://github.com/Polymer/lit-html/issues/1413. As noted in that issue, you can use the permissive PropertyDeclarations type to avoid the issue, but it's also not clear why spreading superclass properties wouldn't work here.

@daKmoR We've addressed the static styles type issue by making css return a CSSResultGroup which is a single result or an array. This should address the core issue without incurring the migration pain of changing the type. Let's process any feedback on that approach in a [lit-next] issue.

I'm an Angular developer and I've just started wading into the world of web components for a side project where I really need something much lighter-weight. I'm really enjoying working with LitElement so far, but there are a handful of things I would love to see from a DX perspective.
On the subject of code-sharing primitives: I really miss Angular directives. I know lit-html has something they call directives, but what I'm thinking of is more like something that can decorate an element with additional functionality at the template. A good example use case would be something like Angular Material's Menu Trigger directive:
<button [menuTriggerFor]="myMenu">Open Menu</button>
<mat-menu #myMenu>
  <mat-menuitem>Lorem Ipsum</mat-menuitem>
  ...
</mat-menu

An Angular-style directive is a good fit for this sort of use case because:

Not every <button> should be a menu trigger
Not every menu trigger need be a <button>
It's not just syntactic sugar for a click handler — the ARIA keyboard operability and focus management specs for widgets like this tend to be really complex, so there's a legitimate need to abstract that behavior
Mixins could work, but it's a little clumsy needing to define a whole new element class to capture every possible intersection of any given set of common behaviors

On the subject of more granular decorators: this is a relatively minor concern, but I wonder if it would be possible to break up some of the decorators that currently take an "options" object parameter into smaller, composable decorators?
I.e., instead of:
@property({
  type: Boolean,
  reflect: true,
  attribute: 'aria-disabled',
})
disabled: boolean;

I think something like this would make for a nicer syntax in addition to offering more flexibility:
@reflect('disabled', { converter: toggleAttr })
@reflect('aria-disabled', { converter: toString })
@property(Boolean)
disabled: boolean;

As a side note, I just looked up the current property API and realized that's not how that currently works at all. :P The way I'm picturing this working is that you would set the property via the actual property name (?disabled=${foo}}), and the reflect decorators would separately reflect the value to the given attribute name in the DOM via a to-attribute converter.
If you wanted to bind its value via a different attribute name from the outside, and/or specify a custom from-attribute converter, I would probably suggest something like this:
@reflect('disabled', { converter: toggleAttr })
@reflect('aria-disabled', { converter: toString })
@property(Boolean, { alias: 'isDisabled', converter: coerceBoolean })
disabled: boolean;

<!-- Input: -->
<my-element ?isDisabled=${foo}></my-element>

<!-- If foo == true, renders: -->
<my-element disabled aria-disabled="true"></my-element>

<!-- Else, renders: -->
<my-element aria-disabled="false"></my-element>

Thanks for the suggestions @dannymcgee
On the directive front, I do think we'd be able to accomplish what Angular does there with a lit-html directive. A directive on an element can add event handlers, set attributes, accessibility object-model properties, etc.
Currently such a directive would require an attribute binding to be attached to an element, but we're working on "element position" bindings which would make it syntactically more natural. Something like this:
html`
  <button ${menuTrigger('myMenu')}>Open Menu</button>
  <mwc-menu id="myMenu">
    <mwc-menuitem>Lorem Ipsum</mwc-menuitem>
    ...
  </mwc-menu>
`

The menuTrigger directive would need easy access to the host, which we're also planning on adding, so that it could query for the menu element. It would then setup the appropriate click, keyboard listeners, and ARIA roles.
Another approach for associating the elements which I like, would be to use a ref so there's an explicit connection w/o any querying:
const menuRef = new Ref();
html`
  <button ${menuTrigger(menuRef)}>Open Menu</button>
  <mwc-menu ${ref(menuRef)}>
    <mwc-menuitem>Lorem Ipsum</mwc-menuitem>
    ...
  </mwc-menu>
`;

@sorvell @kevinpschaaf this is a great use case we should prototype. @dfreedm would this make sense to add to MWC?
The decorator ideas are interesting, especially being able to reflect to multiple attributes. Our big constraint there is that we have a relatively small breaking change budget for this release and we want it to be mostly a drop-in replacement. We may be able to do something additive.
One issue on the API is that we create an associated attribute for setting a property by default with @property, even though we require an opt-in for reflection. If we moved all attribute-related features to a separate decorator, which would include the type and converter, I could see something like this:
@attribute('disabled', {type: Boolean})
@attribute('aria-disabled', {converter: booleanString})
@property()
disabled: boolean;

The differences here are that we have no type or converter for the property, because the property itself doesn't manage any serialization, only the attributes do. I don't think you need an alias for the property in lit-html, since you can bind to the property directly:
html`<my-element ?isDisabled=${foo}></my-element>`

If you want to set this up from plain HTML, you could set either the disabled or aria-disabled and the reflection could take care of setting the other, though that's a bit weird in terms of expected HTML element behavior, and has a cycle that could be a problem with non-coherent converters.
Again, I don't think we could do this by default for 3.0, but we could aim for more modular decorators in the future. One nice thing about decorators is we can offer different sets of them that operate on the same underlying metadata. We'd probably want to avoid documenting multiple ways of doing things though.

A directive on an element can add event handlers, set attributes, accessibility object-model properties, etc.
Currently such a directive would require an attribute binding to be attached to an element, but we're working on "element position" bindings which would make it syntactically more natural. Something like this:

That's awesome to hear, thanks for the response! I haven't gotten the chance to really play with lit-html directives yet, but the examples I saw mostly revolved around control structures (like a "structural" directive in Angular). The element position binding syntax looks really exciting.

The menuTrigger directive would need easy access to the host, which we're also planning on adding, so that it could query for the menu element.

If a directive is always a function that gets called from within an html tagged template, which (in the context of lit-element) is always returned from a LitElement.render method, would it be possible to just do something like this?
function menuTriggerFor<T extents HTMLElement>(this: T, menuSelector: string) {
  let menu = this.querySelector(menuSelector);
  ...
}

Though if you're using an ID you wouldn't even need any knowledge of the host element:
function menuTriggerFor(menuId: string) {
  let menu = document.getElementById(menuId);
  ...
}

@dannymcgee Using document.getElementById(menuId); might not work well in all cases since the menu need not be always in the parent dom, rather can be nested within a shadow dom of multiple levels and so, just a plain id selector wont find it. Therefore in my opinion, passing the reference to the object directly (without ID or class) might work better.

Ahh, I forgot about shadow DOM. What a time to be alive.

Maybe lit-element/lit-html ecosystem can provide something like Protractor for Angular?
Motivation: E2E, with Shadow DOM involved, is still a huge pain (unless I'm missing something). Manually querying every shadow root on the path to the target element introduces a lot of friction and is very fragile. Usually we have trees about 5-6 levels deep. Given that, writing E2E tests is on the edge of being practical at all. There are solutions, but they more like ad-hoc hacks than universally approved way of doing things, so this blocks forming of proper reusable infrastructure.

Maybe lit-element/lit-html ecosystem can provide something like Protractor for Angular?
Motivation: E2E, with Shadow DOM involved, is still a huge pain (unless I'm missing something). Manually querying every shadow root on the path to the target element introduces a lot of friction and is very fragile. Usually we have trees about 5-6 levels deep. Given that, writing E2E tests is on the edge of being practical at all. There are solutions, but they more like ad-hoc hacks than universally approved way of doing things, so this blocks forming of proper reusable infrastructure.

Playwright might be a helpful tool for that. No?

Maybe lit-element/lit-html ecosystem can provide something like Protractor for Angular?
Motivation: E2E, with Shadow DOM involved, is still a huge pain (unless I'm missing something). Manually querying every shadow root on the path to the target element introduces a lot of friction and is very fragile. Usually we have trees about 5-6 levels deep. Given that, writing E2E tests is on the edge of being practical at all. There are solutions, but they more like ad-hoc hacks than universally approved way of doing things, so this blocks forming of proper reusable infrastructure.

I'd rather point to https://modern-web.dev/docs/test-runner/overview/

Thanks @motss @maartenst ! Good to know that people are shifting from the horrible ">>/>>>/:deep". There are alternatives beyond playwright, that support this, but it looks like everyone is doing their own thing.
Anyway, given that playwright indeed gains more and more popularity, my comment is not so valid I guess. Too bad we are stuck with Selenium for a couple of years.

Like said in this issue:
https://github.com/Polymer/lit-element/issues/1101
Add support for event handlers in html code:
<my-component onmycustomevent="(function()(e) => alert(`MyEventValue: ${e.detail.myeventvalue}`))();></my-component>

@MichaelPeter Custom events are already supported since the beginning. Refer https://lit-element.polymer-project.org/guide/events#custom-events

@tvvignesh : Thanks for the answer, did not know this was also possible for custom events and outside of components.

A missing feature that I forgot to mention in my last comment: I would love to be able to extend element classes other than the generic HTMLElement. I realize the utility of this is kind of limited since there are so many base elements you can't append a shadow root to, but it would still be great to have the option. It seems like it would be relatively easy to pull off by just turning LitElement/UpdatingElement into mixin functions:
@customElement('my-element')
class MyElement extends LitElement(HTMLTableElement) {
  ...
}

<table is="my-element"></table>

If I am not wrong, it should already be possible (https://github.com/Polymer/lit-element/pull/228) but not documented as mentioned in https://github.com/Polymer/lit-element/issues/829

Awesome, thanks for the info @tvvignesh!

#829 is about writing mixins that extend LitElement, not making LitElement itself a mixin. We're not very interested in pursuing making LitElement a mixin since Safari/Webkit will not implement customized built-ins. We don't want to encourage making elements that require polyfills forever for a significant number of users.

...Safari/Webkit will not implement customized built-ins. We don't want to encourage making elements that require polyfills forever for a significant number of users.

Damn, I didn't realize that; thanks for the info. Totally understandable.

Bind properties to pseudo class using javascript

Quick suggestion: Vue-like event modifiers.
For example, I have a modal like
<div class="shade">
  <div class="body">...</div>
</div>

and I only want the modal to close when the user clicks on the shade, and not on the body. Would be nice being able to do something like
<div class="shade" @click.self="${() => this.visible = false}">
  <div class="body">...</div>
</div>

@Atulin we're very sensitive to the bundle size and to adding too much special syntax into the template strings. .prop, @click, and ?attr are probably about as far as we want to go.
In JS we have more flexibility and can have pay-as-you-go helpers. For your example, something like this should work:
class SelfEventDirective extends Directive {
  render(listener: EventListener) {
    return listener;
  }
  update(part: EventPart, [listener]: DirectiveParameters<this>) {
    return (e) => {
      if (e.target === part.element) {
        listener(e);
      }
    };
  }
}
const self = directive(SelfEventDirective);

html`
  <div class="shade" @click="${self((e) => this.visible = false)}">
    <div class="body">...</div>
  </div>
`;

A directive is only necessary in this case to get a reference to the target element. Many of Vue's modifiers are implementable without a full directive. lit-html supports event listener options already on the listener. In LitElemetn we expose this via a decorator:
import {LitElement, eventOptions} from 'lit-element';

class MyElement extends LitElement {

  render() {
    return html`<button @click=${this._click}>Click Me</button`;
  }

  @eventOptions({once: true})
  _click(e) {
    console.log('click');
  }
}

You can do that inline as well:
    return html`<button @click=${{handleEvent: () => console.log('click', once: true}}>Click Me</button`;

Maybe we should look at the remaining Vue (and Angular, etc.) modifiers and see if we should vend helpers for any of them.

@justinfagnani, I eventually solved it fairly painlessly with
<div class="shade" @click="${() => this.visible = false}">
  <div class="body" @click="${e => e.stopPropagation()}">...</div>
</div>

but @click.self or something to that effect would certainly be nicer to use. I agree that bundle size should take the priority, though.

i would like "virtual components" which do not need to be globally registered to the dom via customElements.define
html`<${MyVirtualElement} some-attr="some-value"/>`

i've been thinking about this lately, as it would be useful for creating "internal" components that don't clutter up the global namespace, and also for dynamically applying mixins:
const MySpecialElement = myMixin(MyVirtualElement)
html`<${MySpecialElement} some-attr="some-value"/>`

let me know if lit-element already has this capability by some mechanism

@chase-moskal the entire Lit project is oriented around using the standard HTML component model and not creating our own.
The scoped custom element registries proposal is intended to solve that problem for all custom elements, not just component used in Lit.

@justinfagnani — the custom element registries proposal looks great!
is there a good way we could develop a polyfill for custom element registries?

One issue on the API is that we create an associated attribute for setting a property by default with @property, even though we require an opt-in for reflection. If we moved all attribute-related features to a separate decorator, which would include the type and converter, I could see something like this:
@attribute('disabled', {type: Boolean})
@attribute('aria-disabled', {converter: booleanString})
@property()
disabled: boolean;

...
Again, I don't think we could do this by default for 3.0.

@justinfagnani
As I am absolutely in favor of this more modularized approach to the decorators despite the fact that it is a bit more verbose and regarding the changes that I've been following in the pre-releases of LitElement 3.0 (specifically 3.0.0-pre.1), I wanted to know in which direction is the decorators headed.
As I understand, the @internalProperty has been renamed to @state  and that's about it for decorators in the v3.0. It is of course an improvement but does it mean that @state and @property are going to coexist for v3.0? And if it is the case because of the lack of breaking-change budget for v3.0, is it going to be changed in upcoming major releases, and what would be the goals?
Also, on a somewhat-related note and problem that I faced with LitElement 2.0: recommending @internalProperty (@state in the future) decorators to be private via tooling has the huge disadvantage of not being able to turn on the attribute reflection. I always needed that solely to be able to write conditional CSS selectors, not that the property was really supposed to be public. This is one of the reasons I really liked the modularized approach to the decorators.

Could somebody look at https://github.com/Polymer/lit-element/issues/1152 and tell me if this is a legitimate scenario.
Perhaps there could be some way to optionally await the Event Loop to be empty in the render/firstUpdated functions?
render() {
  await eventLoopEmpty();
  return html`
  <div>
    ${mapChildren((el, index) => {
      ...
    })}
  `;
}

Would that make sense or is that a bad idea?

@LukeTOBrien render() is always synchronous. If you don't have all the data needed for a render, render some kind of placeholder state and re-render when the data is available. We really encourage this approach of scheduling renders asynchronously when data is available, and writing render to handle whatever state the component is currently in.
As for children, it's already possible to iterate on children and dynamically create slots. <model-viewer> does this for it's dynamic label system. I would recommend using an unnamed slot, and the slotchange event to trigger a new render (with this.requestRender().

@justinfagnani What about another callback that fires after the children have been rendered, say childrenRendered()?

render some kind of placeholder state and re-render when the data is available

I am finding that in the firstUpdated even the children aren't available, so a childrenRendered() would tell me that the data is available, I have a few classes now where I am using setTimeout, even I am using it twice if I want to re-render and then I also have a service class that initialises somekind of logic.
So I have crazy looking code like:
firstUpdated() {
  setTimeout(() => {
    this.requestUpdate();
    setTimeout(() => this.service.init());
  }
}

On a second thought, have you wondered about a custom attribute class, similar to Angular Attribute Directives?
Sometime I would like to add logical behaviour with Java/TypeScript to an element  with nothing to render:
``ts
@attribute('draggable')
export class Draggable extends LitAttribute {
init\firstUpdated() {
// Init draggable
}
}

```html
<div draggable style="width:100px;height:100px;background:blue">
</div>

I'd love some way of handling click-outside events. Something like a built-in clickOutside() function or something of the sort. I did create such functionality but I'd rather have it built-in. Especially since it shouldn't increase the weight too much.

@LukeTOBrien LitElement doesn't render its own children, only its shadow DOM contents. I'm not sure why the children aren't available in your case, but it likely has more to do with the code that's managing your component, than the component itself. We also can't vend a childrenRendered() callback, because we don't know when they have been, and children can change at any time.
I'd recommend building your components so that they don't assume the children are done being "rendered" at any one point in time. You can do this with an unnamed <slot> and listening for the slotchange event.
Regarding "attribute directives" we already have something very similar with lit-html directives.

@Atulin the way we build functionality in lit-html and LitElement is to only include what's absolutely necessary and can't be separated out in core. Optional functionality is in other modules like directives, decorators, and new in Lit 2 - controllers. Something like clickOutside seems fine external to the main library. It might be a good candidate for a controller.

Here's one I think you might agree with.
More control over how attributes are converted.
In your defaultConverter you have:
  fromAttribute(value, type) {
    switch (type) {
      case Boolean:
        return value !== null;

      case Number:
        return value === null ? null : Number(value);

      case Object:
      case Array:
        return JSON.parse(value);
    }

So the default Array parser is JSON.parse but I would prefer [string.split](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/split).
I have experimented with different combinations and it seem arrays items needs to be double quoted to be vaild JSON:
<my-element values='["one","two","three"]'>
(Note the single and double quote).
What I would rather have is space seperated:
<my-element value="one two three">
So therefore I think a seperator passed into the @property decorator would do the trick:
@property({ type: Array, seperator: ' '})
values: string[]

You could even do item types:
@property({ type: Array, seperator: ' ', itemType: Number})
values: number[]

Then change the fromAttribute Array case to:
...
case Array:
    if (seperator) {
        return value.split(seperator)// If itemType == Number then .map(x =< Number(x))
    } else {
        return JSON.parse(value);
    }

What do you think?
Space seperated in standard in CSS and there is a lot you can do to make it more customisable:

Given how close we are to shipping, and our desire to keep this a mostly backwards compatible change for component authors, I'd be reluctant to change the behavior of type: Array.
I could however see including a few optional converters, like a ListConverter converter that takes a separator:
@property({converter: new ListConverter()})
items: string[]; // takes "one two three"

@property({converter: new ListConverter(',')})
items: string[]; // takes "one, two, three"

or a MapConverter for exportparts-like values:
@property({converter: new MapConverter()})
items: string[]; // takes "one:a two:b three" similar to {'one': 'a', 'two': 'b', 'three': 'three'}

Another converter we've thought about before is an enum converter that has a fallback for invalid values.

@justinfagnani  I have been thinking and I also think an optional converter function would be useful:
@property({converter: new ListConverter(',', (str: string) => str.trim().split(' ')
                                                                                .map(x => Number(x))}
items: Vector3[]; // Takes "1 2 3, 1 2 3, 1 2 3"

The with an optional convertor function you could have unlimited different convertions.

Note the .trim() to remove the spaces so we allow for "one, two, three" as well as "one,two,three".

Given how close we are to shipping

How close?

(Please let me know if this should be made its own issue. I'm not sure if this would be a bug report or a feature request.)
What about guaranteeing String prop types if external logic triggers the removal of HTML attributes?
Example
Let's look at the following custom element consumption and its definition
<script src="my-demo-element.js"></script>
<my-demo name="john doe"></my-demo>

/* my-demo-element.js */
import { html, LitElement } from 'lit-element'
import { ifDefined } from 'lit-html/directives/if-defined'

class DemoElement extends LitElement {
  static get properties() {
    return {
      name: { type: String }
    }
  }

  constructor() {
    super()

    // default value if not defined via HTML attribute
    this.name = '' // isolated from the rest of the property definition (opportunity for better dev experience)
  }

  render() {
    return html`<div name="${ifDefined(this.name)}">${this.name}</div>`
  }
}
customElements.define('my-demo', DemoElement)

LitElement makes use of attributeChangedCallback(attr, oldVal, newVal) and observedAttributes internally to keep the prop in sync with the attribute and perform necessary type coersion.  So when the element is first created, attributeChangedCallback() applies this.name = 'john doe'.  Changing it to <my-demo name="jeff"></my-demo> will apply this.name = 'jeff'.  Current type coersion behavior works well, but only as long as the attribute remains present on the element instance.  When the [name] attribute is removed from the instance (either explicitly or implicitly through 3rd party virtual dom reconciliation), the newVal passed to attributeChangedCallback() will be null, and LitElement internals will apply this.name = null, making it of type object (very much not a string).
The ifDefined() directive from lit-html used to only support undefined as the only "undefined" value, but I see that it has already been updated with the nullish coalescing operator (??) to account for both null and undefined values (:+1).
Workarounds
This simple example could be updated to use a custom converter, but that would require tedious work to implement consistently across a suite of custom elements, especially given that assignment of a default value has to be applied in the constructor().  However, the logic seems simple enough that it would make sense for it to be baked-in to LitElement itself.
Suggestion
Instead of a blind pass through for { type: String } props, LitElement should either:

coerce null attribute values into an empty string ('')

only works for String types (quick fix, but less complete solution)

support a default option when defining properties, that is used when newVal is null

works for any property type (probably not as quick, but a more complete solution)

If option 2 were chosen, the custom element definition would look something like the following:
/* _props.js */
export const Name = {
  type: String,
  default: '' // if present, automatically applied in constructor()
}

/* my-demo-element.js */
import { html, LitElement } from 'lit-element'
import { ifDefined } from 'lit-html/directives/if-defined'
import { Name } from '_props.js'

class DemoElement extends LitElement {
  static get properties() {
    return {
      name: Name
    }
  }

  render() {
    return html`<div name="${ifDefined(this.name)}">${this.name}</div>`
  }
}
customElements.define('my-demo', DemoElement)

Closing this issue as Lit 2 / LitElement is now in a stable release. Please open new issues for any feature requests.


Pokestop api endpoints

adds POST /api/pokestop-positions to get pokestops within a specified geofence
adds GET /api/pokestops/id/:fort_id to get the specific PokeStop

looks good to me; we still have inconsistent policy around re-ordering imports.  I think goland and vscode can be configured in the same way we just need to decide


Force layout - Mirror edgeLabel problem

Version
4.2.0-rc.2
Reproduction link
https://gallery.echartsjs.com/editor.html?c=xUhc8bMDbM&v=1
Steps to reproduce
Force layout - Mirror edgeLabel problem

open the link of reproduction.
drag the node which name is "父" (Father)
see the edge Label, it show '父子'at first, but when you drag the node around, the mirror edge label will show '子父', but it should be '父子'

What is expected?
What ever you drag the node to anywhere, the edge label will still show 父子,  instead of 子父' (read from source: 子 to the  target : 父).
What is actually happening?
the mirror edge label show 子父

Because of reading habit, is from left to right, so this problem might make some people confuse the information is correct or not.

Sorry, I couldn't reproduce it, the edge label is always '父子', but I'm using the latest version, maybe you should try version 4.2.1?

@susiwen8 Hi, maybe I use photo will let you easier to undeerstand

This photo show 曾國荃 link to 曾國藩, edge Label is 兄弟 which is I want.
( '弟' is closer to '曾國荃')

But this one, the edge label '弟' is closer to '曾國藩', but '曾國藩' is should be closer to '兄'

@susiwen8
Is there any option can make the edgeLabel position is fixed(maybe just always show the label at one side) ?

OK, I get it, you may misplace 'What is expected' and 'What is actually happening'.

@susiwen8
Is there any option can make the edgeLabel position is fixed(maybe just always show the label at one side) ?
@DieYiSu From docs, there is none,
This is a new feature rather than bug.

Mirror label is little tricky, especially for non chinese speaking user. For example 'father and son' to 'son and father'
edgeLabel position we may look into it.

so currently this problem looks like doesn't have the solution ? thanks

Currently, I believe this is not possible with ECharts. And I think this is not a frequently used feature so I guess it should not be a new feature.
But for your particular need, I think you need to change the source code by yourself if you insist on this feature. Basically, you need to change the rotate of edge label. It may be related to src/chart/graph but I'm not sure. I'm afraid that's all I can help.


personalize message error UnknownVersionException to spanish

Q
A

Bug?
no

New Feature?
yes

Framework
Laravel

Framework version
5.7.y

Package version
2.4.y

PHP version
7.2

Actual Behaviour
Add message language exeptions

Hi, this is not really the responsibility of the package, but yours as developer of the application.
There's a lot of exceptions that get thrown around, and most of them are not even inside of this package. If you need to return localised error messages, you should set the exception message yourself.

Hi, this is not really the responsibility of the package, but yours as developer of the application.
There's a lot of exceptions that get thrown around, and most of them are not even inside of this package. If you need to return localised error messages, you should set the exception message yourself.

I disagree. For example, the exception when the Accept header is not sent. That exception is not documented so it is very tedious to look for the exceptions and know what is the class to make a hook according to the instanceof and so now that is with one but now with many it is a tedious task.

@FuriosoJack Yes but, these exceptions are not actually meant to be read by humans, they are meant to be read by either other APIs or developers debugging them.
You should not display these exceptions' messages to your end users - only things like validation errors (which are translated).