I am trying to make a tabbed windowing system within a webpage using om-bootstrap's "pills" navigation by adding tabs when links get clicked and removing tabs when an X button on the tabs is clicked.
I need to know how to add and remove data from the global state/store and create a macro that can be used to declare a tab app component and make it remove itself when it is no longer alive.
What is the best way to reference the global state? How can I make a component remove/unmount itself when it gets closed?
Since removal of a subcomponent affects its owner, you should let the owner (i. e. the "tab system") know that this tab needs to be closed/destroyed/obliterated.
I've digged through todomvc example (live) assuming your process of destroying tab panes is pretty much the same as destruction of TODO items there. I see nothing ocnflicting so far. Here are my findings:
A channel is used.... When application starts (IWillMount), a (chan) (from core.async) is written into application state at :comm key.
...for event handling.... Events from the channel are handled in the loop following that code, in go-form, asynchronously with the block it appears in (with <! being a "kinda blocking" operation). Well, you may know it, I didn't, still learning what is CLJS all about.
...that is passed to all child items' init states.... So it becomes a way for children to send events to the root. I'm starting to like this.
...so they can send events to their parent! This is done in put! calls with the comm channel, fetched in the linked line. Events put there are handled by the loop defined in (2), which delegates them to appropriate functions depending on type (accompanying keyword).
I'm nowhere near a ClojureScript pro, but I'm learning. So if the above doesn't make sense, this is normal and means I didn't understand something. If that turns out to be the case, putting me back on track would be much appreciated.
Related
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.
I was working on an HTML block in Concrete5 located in the footer. I made a javascript call - can't quite remember it, but I think it was referencing either jQuery or the Google Maps API. Anyway, now the block won't display and oddly enough, I am completely unable to modify/add/remove blocks now. I'm pretty sure it is because of the javascript call it is making, but I can't modify or delete the block to fix the issue.
What am I supposed to now? I tried disabling javascript in my browser but of course that won't let me modify the blocks either.
I don't know 5.8+ that well yet, but this may be unfixable from within the UI.
If the error is in a global area, your best bet might be opening the template, changing the area name where the global area is used and displayed, and recreating it from scratch.
You'd be looking for something like this:
$a = new GlobalArea("Footer Nav");
and change the global area's name, thus creating a new one.
If that's not an option, you may have to resort to deleting (or altering) the faulty block through the API.
In my experience, the easiest way to get a blank page that has C5 bootstrapped is creating a custom Dashboard page:
It's a common task for a Concrete5 developer to create their own Dashboard pages. Dashboard pages are just single pages located inside the "single_pages/dashboard" directory. Once they're added within that location, they automatically show up in the Dashboard.
Now, as to how to edit or delete the block inside the area, I don't have a complete recipe, but this example page showing advanced area operations should get you started.
The API documentation for GlobalAreas is here, for Block here (notice the delete() / deleteBlock() methods.)
FYI although the solution marked as best works, it leaves data in the database that will stay there forever and forces you to change your area's name which might be ok once but not if it happens again and again.
Since that was an HTML block, the best way was to go to your database's interface, probably phpMyAdmin, go into the table "btContentLocal" and do a search for the faulty code you had entered in the HTML block then fix or delete it.
Like that you're back to normal, you don't leave stuff behind, and you can keep your area as it is
After reading Marionette.Commands I am very curious to finding difference between normal functions and Marionette.Commands.
If you define any function, you can call that function wherever you want.
normal Function :
var normalFun=function(){alert("Normal Function")};
same way Marionette.commands also working like in the following way.
//creating instance for Application class
var myApp=new Marionette.Application();
//registering command
myApp.Commands.setHandler("functionName",function(){alert("This is just a normal function but way of defining as different in my point of view.")});
//whereever you want to call this command just run that command with corresponding name
myApp.Commands.execute("functionName");
What I am thinking, both normal functions and Marionette.Commands are same. If it is right then why did Marionette developers develop this Marionette.Commands concept?
To use a function, you need to either call it from the same scope, or have a reference to a containing object. This isn't the case for commands, so they allow for decoupling.
Say you want to change the color of the menu when a user clicks on some button in your app. You can define a changeColor function in (e.g.) the portion of your application that manages the header. Then, you can make the menu color change by calling (e.g.) myHeader.changeColor() from somewhere in your application. But as mentioned above, that means you need a reference to myHeader to be able to call its changeColor method.
As you develop your application, you realize that actually the menu itself is getting quite complex, and it makes more sense for it to change its own color directly (instead of having the header manage the color). Now you need to go in your application and change every instance of myHeader.changeColor() to myMenu.changeColor(). This is due to the coupling of the various bits of your application.
If instead you use commands, you would execute the command from the places that need to change the menu color, and you'd define the handler in the "header" part. Then when you decide to change your application design, you can simply move the handler so it's defined in the "menu" part. With this solution, you won't have to change the actual calls to change the menu color, because they're entirely decoupled.
With both solutions, you can change the menu color. But using commands allows for better decoupling and less work down the road. Of course, this doesn't mean you should use commands everywhere: adapt their use (or not) to your particular case.
They are the same. I mean everything is the same down the road (a function), always. Haha.
What's important is what you make out of it. So, in the end, it is just a matter of taste/professionalism (respecting patterns, conventions, etc..).
With the commands, you have everything in one place and only myApp is responsible for communicating between the modules/the controllers/the domains/whatever "functional end result" (to quote #David Sulc very good book: "Backbone.Marionette.js: A Gentle Introduction") of your application.
So long story short: In a big app, it makes sense to only pass around the myApp instance, and executes the commands from there.
Note: And that makes even more sense when you're using RequireJS.
That's cleaner, more structured.
I'm working on a web app in Google closure where the structure is something like this:
App
+ Control Pane
| + Search Box
| + Search Button
+ Result Pane
+ Results
+ Next Page Link
The actual component structure is quite a bit more complex. The important point is that there are many different components all over the component tree that can initiate certain actions. In this example, hitting enter in Search Box, pressing Search Button, or hitting Next Page all require a query to be made.
This is simple enough to handle. Any child anywhere in the component tree can do
this.dispatchEvent(App.EventType.ACTION, ...)
App will be able to listen to it when the event propagates upwards. The problem is the other direction: When App receives data from its query, it must push it to all children.
It seems very brittle for App to try to push directly to Search box and Results, as their location in the component tree is subject to change. What I'd like to do is fire an App.EventType.DATA_RECEIVED event and have all children (and sub-children, etc.) hear it.
The only way to do this in google closure that I've been able to find is to make a global public singleton instance of App and use as the source for all App.EventType.DATA_RECEIVED events, or to plumb App through to all children and subchildren.
Both of these are messy and brittle in their own way.
Is there a simple way in closure to dispatch events that bubble downwards?
It's not a very satisfactory answer, but it's what I settled on:
There's no good way to communicate such things down the component tree. Even closure itself bumps into this problem, passing opt_domHelper down the tree to every subcomponent.
My suggestion is to subclass goog.ui.Component for your app and create a myapp.Environment class, which contains both opt_domHelper and other environment variables, such as one event listener designated as the application's event channel.
It's not a good solution, per se, but it's the least of all possible evils. And if you've already been dutifully passing opt_domHelper everywhere, then it's no worse a problem: that plumbing becomes more extensible, and the opt_domHelper itself is hidden from implementors (who now pass around environment instead).
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.