There is a js file that is built using the Laravel Mix. It previously had 2 components, after which there was a need to register a new one. After I registered all the necessary logic, I decided to launch it. Assembled bundle. I check. Does not respond to pressing. Everything is correct in the code. There were no errors during assembly. The developer console is also empty. I decided to just write console.log. You never know. Nothing helped. As a result, I made a copy of current_ source.vue, and in the original I erased everything and wrote simply
<template>
<v-btn #click="console.log('adfesfwf')">ajvarhe</v-btn>
</template>
Yes, yes, I have Vuetify connected. Buttons are correctly displayed, but in the console, by pressing, it is empty. At the same time, I use DevTools for Vue, where it is very convenient to view dispatched events. For all the time debugging this error, not a single event was recorded. At the same time, hooks work (checked only created). I tried to create a completely different component. Exactly the same problem. I want to draw attention to the fact that the previous 2 components work correctly. How many rebuilds were there, events work.
If you want to subscribe to a native event, you must use a special modifier native.
In your case, it will look like this <v-btn #click.native="console.log('adfesfwf')">ajvarhe</v-btn>
Related
Working on an application that pulls the current user to use as the default user. Using React 16.
So I am having a problem that I can't seem to find the solution to, hopefully fresher eyes than mine might be able to see a way to handle this. But first a little React knowledge.
React works in components. When a component is called, it has a couple of stages that it goes through before actually displaying any code.
constructor - the component is initiated, any data/structures that the component needs are created here.
componentDidMount -- once the component is created, they this where the data that it needs is loaded. For example, if you needed to display a list of items, those items would be loaded here.
render - this is where the html is created for the component is built. This is what displays things in the browser.
Obviously there is a lot more going on under the covers than just this, but this is sufficient for illustration purposes.
So my problem is I need to default some input in the render to show data that is supposedly loaded in the componentDidMount. But that doesn't seem to be happening. Instead, the data that I need is being loaded after the render.
I feel that either I am not understanding correctly how React does these things, or I need to create some sort of delay to allow the data to load completely before the render.
Can someone help me, direct me to a resource that could help, or tell me what I am doing wrong?
TL;DR: Deleting the DOM Element of a custom Element created with Angular Elements will lead to sub-routers not loading components
First, the code is available at Github.
Sadly, I did not get a stackblitz version running, but locally, after a clone, npm install and ng serve it should run fine.
About the general structure:
The Project shows an example of a WebComponent exposed by an Angular App via Elements.
The WebComponent is used in the index.html, which is referred as container Application.
The use case here is a little bit constructed, but the navigation that occurs, when clicking
on the two top bottoms is comparable to the real world use case.
Normally this WebComponent would have been used in an AngularJS legacy Application. Since there are many overlappings between the two root views (overview1 overview2) it is used in two AngularJS components, in between ui-router handled navigation. This means, that exactly this constructed actions happen. The DOM Elements will be deleted and re-added.
So basically the problem is:
If I am deleting DOM Elements of a WebComponent (so deleting the CustomElement itself) from external, and then re-adding it with another route, The Child-route components of this will not get loaded. If there is a short delay (50ms), everything works fine.
To reproduce the problem:
Load page and click an the "switch with delay" button.
Reveal Detail Component
Switch to the other Overview by clicking "switch with delay" again.
Reveal Detail Component
=> Everything should work fine
Repeat the same steps, but this time click only on "switch directly".
Prior Investigations
What I already debugged is the Router. So I went through the log messages with "enable tracing"
and they seemed to be no differences. Afterwards I compared the Components' Lifecycle and
the thing I noticed is, that in the working example the old Detail**1**Component Object will get destroyed a new Detail**1**Component one will be created and directly destroyed afterwards and then everything regarding the Detail**2**Component will get constructed.
On the not working example it is like this:
A new Detail**1**Component will get constructed again and destroyed afterwards. Then the old Detail**1**Component will get destroyed. Then nothing regard the Detail**2**Component will get constructed.
So routing seems to work fine, but components won't get loaded in this case, maybe due to a strange lifecycle, because of the Detachment of the View to the ViewModel happening due to hard deleting those WebComponent in DOM.
Maybe I am just dumb and did something fundamentally wrong, but I could not find anything in the Web regarding this problem and every solution I tried by myself just resulted in a workaround like establishing a delay.
You can find a workaround available on Github.
I forced the recreation of the DOM object by attaching a boolean
to the navigation button, which will determine if the DetailComponent
should actually get shown.
<router-outlet *ngIf="shown">
Then the Outlet will get reevaluated and the DOM will get refilled on clicking the button.
This will effectively mitgating the issues described.
In my opinion its not the cleanest solution, but cleaner than a timeout, that
even needs to get applied from the outside.
I hope this was helpful and maybe someone might point me to the actual fix and
not only workaround.
Since this was my first question do not hesitate to give me feedback on formal
appearance.
This is pretty strange. I have an Angular directive that is part of an ng-repeat, and there are no elements in the ng-repeat's source array until a specific action is performed by the user.
Once that action is performed, the array is populated correctly and the element is added to the DOM -- but doesn't actually render. On literally any DOM change -- altering any CSS property of any element on the pages, resizing the page, anything -- the element appears as expected.
Not sure what code would actually be useful to help diagnose this problem, but I'm happy to provide anything relevant.
Other relevant information: Works as expected in Safari, using Ionic framework.
It's not enough that the user perform an action, Angular must find out that the user has done so. You are supposed to inform it by calling $digest() but as that can fail if you are already in a digest call, I just call $timeout().
Recently I am finding difficulty understanding whats happening in a CoffeeScript/Backbone app. Its hard to trace whats happening quickly without a very slow step through. The problem I think is: I know an event is triggered (Backbone view event). But I dont know which functions are called because of it. There maybe more than 1. I may not even know with view partial is the event defined (so I cant put a breakpoint?)
Is there a debugger which plots the execution of the program as a graph? So that I can zoom into what I need, or maybe something I can use to "visualize" the execution of my code. Maybe not, if what should I be looking out for. I am not sure where I need to put a breakpoint since I dont know where some events are triggered. Then sometimes I find it hard to understand why the code step through might be jumping here and there, maybe its multiple events and their handlers executing?
Everything in Backbone (Views, Models, Collections, Routers) extends Backbone.Events. That means they have an _events property that contains each bound event (e.g. change) with an array of their subscribers.
In order to access this open your javascript console in chrome, firefox or safari (or anything but IE) and enter the name of a globally accessible instantiated object with ._events at the end. E.g.
products._events
After pressing enter you should be able to expand this and see what is published and subscribed.
I've written a Mac OS X Dashboard to show the StackOverflow flair of yourself and other people.
My problem is that whenever I update that widget to a new version, all previous instances are removed and a single new instance is created on the Dashboard. So if you previously followed the flair of 4 people you'll have to recreate the widgets and enter their user-IDs again. :(
Is there any way to keep all running instances while updating a widget?
Checking the preferences file, I see that a new instance is created after a new version of the widget is deployed. Is this by design? Does all widgets work like this, by any chance?? If so, can this be manually circumvented somehow?
You can find the widget in question, including the project files, at http://widget.huxhorn.de
I've changed the code in remove() to set the preferences to the correct values instead of null as suggested below - but this doesn't help, either.
What's my mistake?? Help! I'm stuck!
The other problem of my widget has been fixed:
I accidentally called
widget.preferenceForKey(null, dashcode.createInstancePreferenceKey(userIdPrefKey));
instead of
widget.preferenceForKey(dashcode.createInstancePreferenceKey(userIdPrefKey));
but this is now fixed (not yet released).
I know about this tool that takes over the install process: http://junecloud.com/software/mac/smart-widget-installer.html
(source: junecloud.com)
I think your calls to setPreferenceForKey and preferenceForKey look strange. Where does that null come from. Shouldn't they look like
widget.preferenceForKey(dashcode.createInstancePreferenceKey(userIdPrefKey))
widget.setPreferenceForKey(value, dashcode.createInstancePreferenceKey(userIdPrefKey));
Does the syntax with null
widget.setPreferenceForKey(null, dashcode.createInstancePreferenceKey(userIdPrefKey))
in remove() delete the preference? That would explain you situation I guess. On Update the remove() gets surley called and thus on restart of the widget the preferences are gone.
I guess there is only one way to keep your preferences during an update. Create one preferencekey without relying on dashboard.createInstancePreferenceKey but instead think yourself of a unique key value.
In this preferenceKey you could then save all ever entered userids (by any instance) with a growing (say comma seperated) list. When a widget instance is opened an the widget.preferenceForKey(dashcode.createInstancePreferenceKey(userIdPrefKey)) isn't already set you could let the user choose one of those by giving him a select or such a thing
I was just thinking maybe the update process is nice enough to migrate the preferences to the new verison. Even when you don't remove the preferences I think the widget.identifier (createInstancePreferenceKey) will have changed an thus you can't access the "old" settings.