Fired events lose arguments at parent handler

When firing from child component, handler on parent fires but doesn't receive the arguments. Same applies to fire when done via method call.
Further testing shows that it only loses arguments outside the component. Listening inside the same component works fine. Narrowed it down to reproxying arguments logic for component method calls. Not sure how to proceed from here.
Works on 0.7 (parent handler receives arguments), breaks on 0.8 (parent handler receives blank arguments): http://jsfiddle.net/r9zmsz89/2/
var ChildComponent = Ractive.extend({
    template: '<button type="button" on-click="foo()">Click me!!!</button>',
    oninit: function () {
        this.on('far', function () {
            console.log('on child', arguments); // ['foo', 'bar']
        });
    },
    foo: function () {
        this.fire('far', 'foo', 'bar');
    }
});

var ParentComponent = Ractive.extend({
    template: '<child-component on-far="boo" />',
    components: {
    	'child-component': ChildComponent
    },
    oninit: function () {
        this.on('boo', function () {
            console.log('on parent', arguments); // []
        });
    }
});

new ParentComponent({
    el: 'body',
    append: true
});

This was (some-what) intentional, see #2095, for two reasons:

Using arguments at component boundary requires explicit inclusion.
I didn't put the work in to handle argument passing for event handler syntax.

However, given the lack of 2, and the pre-existing behavior, maybe the thing to do is include all the arguments on a proxy event re-fire.

BTW - You can get your example to work by doing: <child-component on-far="fire('boo', $1, $2)" />

Yeah, tried to "fix" that last night when it broke the tests related to that issue, and then remembered. Was waiting for your input whether this is really a bug (since I've been using it this way for quite some time) or is this a breaking change, and should be a docs update thing instead.

@fskreuz I've got it fixed just implicitly tacking on existing args for event re-fire.
Looking into one other case I thought of which is including ...arguments but not as sole argument, on-foo='someMethod("bar", ...arguments)'

Now that I've used the $1, $2, ... and ...arguments syntax, it makes more sense. The $1, $2, ... allows for repositioning of args, while ...arguments just allows everything in. However, tacking in everything at the end feels confusing. Was thinking more like the following:
// Event style. bar gets everything from foo, like the old behavior. Captured by `on`.
on-foo="bar"

// Explicit, method call. Define what gets passed in. Reposition, additions, rest possible.
on-foo="bar('baz', $2, $1', ...arguments)"
on-foo="bar: 'baz', $2, $1, ...arguments" // Quite confusing. Looks like an event.

// Explicitly saying we don't want to pass anything to method.
on-foo="bar()"

// Explicitly saying we just want to pass everything.
on-foo="bar(...arguments)"

per #2257:

using ...arguments as a spread operator must be last argument (just like normal es6) of method call or will throw parse error
use of ...arguments, $N, and arguments[n] is NOT supported in proxy events per intent to deprecate the expanded parameter syntax that uses :.

using ...arguments as a spread operator must be last argument (just like normal es6) of method call or will throw parse error

you sure about that? I dunno about arguments, but I've been playing with the spread operator in the new node-5.0.0 and they can be mixed...
> var a = [1,2]
undefined
> var b = [7,8]
undefined
> b.push(...a, 3, 4)
6
> b
[ 7, 8, 1, 2, 3, 4 ]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator#A_better_apply

@heavyk Fair enough :D

using ...arguments as a spread operator must be last argument (just like normal es6)

I thought that too until @heavyk's example – I think we were both thinking of rest parameters, which do have to go at the end


Cucumber Tests for Vue Context

Create cucumber tests for VueJs application generation API call.

This was done here https://github.com/jhipster/jhipster-lite/pull/2192


[incubator/jaeger] cannot parse env var JAEGER_AGENT_PORT=udp://<IP_ADDRESS>:5775

Environment:
Infrastructure: Kubernetes v1.11.7
Deployment tool: Helm v2.12.2
Could not load jaeger tracer configuration: cannot obtain reporter config from env:
cannot parse env var JAEGER_AGENT_PORT=udp://<IP_ADDRESS>:5775:
strconv.ParseInt: parsing "udp://<IP_ADDRESS>:5775": invalid syntax
Which chart:
[incubator/jaeger]
What happened:
Installed loki-stack, everything seems fine, but if we install jaeger afterwards and restart loki pod, it will say: cannot parse env var JAEGER_AGENT_PORT=udp://<IP_ADDRESS>:5775
What you expected to happen:
I would expect to be able to run loki and jaeger alongside each other.
How to reproduce it (as minimally and precisely as possible):
Install loki-stack via helm chart
Install jaeger via helm chart
Delete loki pod (it will be in crash)

This is not a problem of this chart, it is actually dependency https://github.com/jaegertracing/jaeger-client-go that fails:
https://github.com/jaegertracing/jaeger-client-go/blob/c58709fe19d793cdd40ad8bfa6e645a40a2eccf8/config/config_env.go#L186
If you install jaeger chart with name jaeger, environment variable JAEGER_AGENT_PORT will be automatically created by Kubernetes (as string) and jaeger-client-go expects integer (just the port number, not url) under the same name so it is going to fail. The easiest way to fix the problem would be to install jaeger under some different name, for example:
helm install incubator/jaeger --name jaeger-tracing
loki will happily work with that ;)


[WIP] feat(module:icon): switch to SVG icons

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/NG-ZORRO/ng-zorro-antd/blob/master/CONTRIBUTING.md#commit
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Application (the showcase website) / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

Icons based on font files.
Issue Number: N/A
What is the new behavior?
Icons based on SVG. 🌟
Does this PR introduce a breaking change?
[ ] Yes
[x] No

But we should make a break change for this in the future.

Other information
It has a new dependency which is included in ant-design-icons (for Angular, pull request is not fired yet).

Recent CSS update is also included in this pull request for previewing the result.
TODO: Doc needs to be updated, and some components broke because of icons are replaced with SVG icons.

Waiting for @ant-design/icons-angular to release. 🎉

Netlify is still not OK. 😢


🚀 Feature: support multiple instances of the same authentication provider

🔖 Feature description
Currently, Backstage only supports 1 authentication provider of each type.
For example, you can't register 2 GitHub auth providers to allow users to login using both GitHub.com and an enterprise GitHub instance.
It would be nice if we could register 2 auth providers of the same type, such as GitHub or Azure.
🎤 Context
Right now there's no way to authenticate using both GitHub.com and a GitHub Enterprise instance.
In our Backstage instance, we have components registered in the catalog coming from both GitHub.com and our GitHub Enterprise instance.
We have components on the component entity page that use githubAuthApi.getAccessToken() to grab an OAuth token for fetching information about the GitHub repo to display.
Because Backstage does not currently support multiple GitHub authentication providers, this functionality breaks for components that come from a GitHub instance that does not have a corresponding auth provider.
✌ Possible Implementation
If you try to register multiple auth providers of the same type (by giving each one a unique key in the YAML and JS object), the frontend defaults to using the first matching auth provider of the same type from the list of ProviderFactories supplied in auth.ts.
Currently the key used for the ProviderFactories object is only used by the backend for determining where in the config to look for the given auth provider's config. I'd suggest adding an optional way to specify this key from the frontend side.
Additionally, GitHub Auth API's getAccessToken() method would need to be updated to support using the right auth provider based on the source location for a given component entity.
👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, but I'm happy to collaborate on a PR with someone else

You could make one of your own perhaps, like a class + interface that accepts a URL and chooses among several underlying OAuthApi implementations based on that URL. Then have your components consume that one instead of just one single ref

Could you point me at some docs and/or code to help me get started with this?
I'd be happy to contribute this back once I get it working. 🙂

We talked a bit about this ticket. There's the scmAuthApiRef which can be used, that I should have remembered already in the first comment. Its API accepts a target URL of the resource to access, so it's able to pick among all the registered integrations to find the right one.
Not many plugins leverage it at this point. But if they do, they will automatically get access to all of the existing integrations, including both your public and private github ones.

@ConnorDY we were looking to also do the same thing, wondering if you had any luck?

I just spent some time showing myself that we can't work around this with a forward proxy. While employing the forward proxy did allow the auth provider to be aware of different tokens for the same domain name, not all plugins become aware of the reverse proxy and thus populating catalog items sourced from two organizations hosted on GitHub was not successful. Instead, the repository discovery plugin was able to create a Location in the catalog but following processing was still linked to use github.com via its spec.target field.
Here's a diagram of the forward proxy config I used to test this:

And the app-config.yaml I used to test it with
    integrations:
      github:
        - host: nginx:3400 #forward-proxy for FIRST org
          apiBaseUrl: http://nginx:3500 # forward-proxy for api.github.com
          token: ${GITHUB_FIRST_PAT_TOKEN}
        - host: nginx:3401 #forward-proxy for SECOND org
          apiBaseUrl: http://nginx:3500 # forward-proxy for api.github.com
          token: ${GITHUB_SECOND_PAT_TOKEN}
    catalog:
      providers:
        github:
          firstOrgRepos:
            host: nginx:3400
            organization: 'firstorg'
            catalogPath: '/catalog-info.yaml'
            filters:
              branch: 'main'
              repository: '.*' # Regex
            schedule:
              frequency: { minutes: 5 }
              timeout: { minutes: 4 }
              initialDelay: { seconds: 8 }
          secondOrgRepos:
            host: nginx:3401
            organization: 'secondorg'
            catalogPath: '/catalog-info.yaml'
            filters:
              branch: 'main'
              repository: '.*' # Regex
            schedule:
              frequency: { minutes: 5 }
              timeout: { minutes: 4 }
              initialDelay: { seconds: 7 }

This would be helpful for us as well since we have two GitHub enterprises. One is an Copilot-only enterprise for everyone. The other is a traditional GitHub enterprise with only the developers that use GitHub.


Coming problems in 2025.1 update of home assistant

Hey,
seems we will have problems in 2025. Is there some update planned for this? Or should we not update anymore?
Problem 1:
Entity None (<class 'custom_components.domintell.climate.DomintellClimateDevice'>) is using deprecated supported features values which will be removed in HA Core 2025.1. Instead it should use <ClimateEntityFeature.TARGET_TEMPERATURE|PRESET_MODE: 17>, please report it to the author of the 'domintell' custom integration and reference https://developers.home-assistant.io/blog/2023/12/28/support-feature-magic-numbers-deprecation
Problem 2:
Entity None (<class 'custom_components.domintell.climate.DomintellClimateDevice'>) implements HVACMode(s): heat_cool, off and therefore implicitly supports the turn_on/turn_off methods without setting the proper ClimateEntityFeature. Please report it to the author of the 'domintell' custom integration
Problem 3:
Entity light.duplex_dimmer (<class 'custom_components.domintell.light.DomintellDimmerLight'>) is using deprecated supported features values which will be removed in HA Core 2025.1. Instead it should use <LightEntityFeature: 1> and color modes, please report it to the author of the 'domintell' custom integration and reference https://developers.home-assistant.io/blog/2023/12/28/support-feature-magic-numbers-deprecation
Problem 4:
light.led_licht_vergeten (<class 'custom_components.domintell.light.DomintellLight'>) does not set supported color modes, this will stop working in Home Assistant Core 2025.3, please report it to the author of the 'domintell' custom integration
Problem 5:
TEMP_CELSIUS was used from domintell, this is a deprecated constant which will be removed in HA Core 2025.1. Use UnitOfTemperature.CELSIUS instead, please report it to the author of the 'domintell' custom integration
Thanks for having a look at it and let us know if we should stop updating if we want to keep Domintell.
Grt Gregory

Hi,
Thanks for the message. Pretty busy with my projects right now. I will try to find some time to update the driver in the second half of December. I an using it myself so I realy want to support upcoming HA in 2025.

Re-open if needed

Dear,
Thank you for your efforts. And indeed. Lights and dimmers don't have problems anymore with your update. But for my leds with Modules DLED I still get errors that color mode is not used. And I'm sorry but do you have plans to update the climate.py too? I tried to change that by myself with help of chatgpt but I can't seem to get it working without errors.

@KrickGregory Climate.py was also updated in the master branch. Let me know if does not work.
I don't know which component you are using for LEDS. Can you post errors here?

It works. Except for the color mode of my lights en espacialy the DLED01, 4 (signaling) LEDs Module. Logfile from five minutes ago after restart and updated py files of you.
home-assistant_2024-12-10T19-41-38.786Z.log
And I realy apreciate your time.
Grt Gregory


Possibility to configure url checker, timeout set to 1s

Url checker timeout can be configured using:
Atmosphere.setup do |config|
  config.url_monitoring.timeout = 123
end

@nowakowski, @tbartynski  please take a look

:+1:


Loading issue

The page didn't present data.

I rechecked the program and I found that in the rule for the database in firebase, it was set to only allow requests up to the 30th of March, but now that I have updated the rule, everything works now.