The react-select 4.0 release notes say that NonceProvider now needs a cacheKey, but it's not obvious what that cache key should be. Can I use the same cacheKey across my entire codebase? One per page? One per component?
Unless they share the same styles you should use a different key per component.
Related
The problem:
I am currently working on a file tree, more specifically on a "Selected Folder" functionality. I'm doing this to have a specific target for creating new files and folders, other that the root folder. (I'm using Vue within Electron, but this is not really relevant to the question)
Selection happens on click. Due to the nature of file trees, I use recursive components (and this limits my 'easy' access to some components).
While achieving this on the back-end is trivial, my exact problem is that while marking the selected folder with, say a different background color or bold text (by binding an id or class that has some corresponding style on my stylesheet), I need to unmark the previously selected directory.
So, how do I gain access to an indirect (due to the recursive components) child component?
What I've tried, and looked into:
Now, I know that within JS you can't store pointers or references in variables (otherwise this would've been easily achieved by storing a reference to the previous DOM element).
I have some solutions up my sleeve, but they're really tedious and not very straightforward. Previously, I had to re-render (by re-reading) specific sub-directories, based on file system updates. I achieved this partial re-rendering by propagating child function calls from the root directory until I reached the directory that needed to be re-rendered. I had to do this since the FS watcher was created on the root component.
Similarly, I could do this with the un-marking task. When I select the new folder, I start by propagating child function calls until I reach the previously selected folder, and un-mark it by un-binding the style id. Having done this previously, I know it's not a pleasant method.
Since I can get the click event target, I wondered if I could somehow store any kind of reference to the previously 'selected' DOM element and just use that reference later when I need to 'deselect' it.
Here's what my folder component looks like. I tried giving self-explanatory names to the properties, but if there's any confusion, I'll answer any question.
<folder-comp
#openFile="openFile"
v-for="folder of folders"
:key="`folder-${folder.shortFolderName}`"
:folder-name="folder.shortFolderName"
:ref="folder.shortFolderName"
:full-folder-path="folder.fullFolderPath"
:local-directory="recursiveScanDir"
:indentation-level="indentationLevel + 1">
</folder-comp>
The propagation method I used was necessary previously since all I had was an event File System path, unrelated to my Vue structures, and so I needed to somehow translate traversing that path. Here, though, everything happens only within the Vue environment, so I thought there would be some sort of way to deal with this easily.
EDIT: Well, as it happened with me in the past, just writing about the problem itself on stackoverflow helped me reach a solution.
I have a Global Event Bus set up on my Vue project, so I can bind an event listener on the currently selected folder. Once another folder is clicked (thus selected), it emits an event in the Global Event Bus, triggering the previously selected folder. This is followed by the un-marking and the unbinding of the event listener.
This is only one solution though, so the question still stands. Is this a good solution? Are there any drawbacks to this approach? Is there a better solution?
Instead of a global event bus, you can also use state management such as Vuex. When you change folders, you simply dispatch an action. This uses an command pattern, as opposed the the mentioned listener pattern. You have the choice to make this action asynchronous or synchronous as well.
There are several ways to register your listeners/watchers, from within components, or outside of them.
Using this architecture will allow you to easily add undo/redo capabilities, and also be able to navigate back and forth through your history of mutations.
You also gain the integrated debug features provided by the Vue tools in your browser.
In fact, Vuex was built exactly for situations like this, when components need to communicate with each other but the parent/child prop/emit/inject mechanisms start to become tedious and and fall apart.
There is a high probability that once you starting using Vuex, you will never look back.
When I look at my application state in Vue's devtools chrome extension, I can see multiple instances of the same component in the tree view. However, there is no way to distinguish one instance from another. For example, in the screenshot below there are three <Todo> components. Imagine instead there are 30. How do I attach some kind of instance name or id to my components? It seems silly to have to click through 30 components to find the one I need.
I had the same idea also a couple of months ago.
So I gave it a try.
My PR has been submitted: https://github.com/vuejs/vue-devtools/pull/331
It's probably a bit early to rely on my solution since the core team could still reject the PR or request other naming conventions.
Until then you can build my proposal version yourself from my repo:
https://github.com/nerdyglasses/vue-devtools/tree/verbose-component-tree
Is that helping you?
Best, Christian
You can use the ':key' attribute. And you even HAVE TO use it if your component depends on a v-for loop.
here you can see the keys
I find, even when assigning the decorator #singleton(false) to the view-model, that while the view-model does then persist as a singleton across activation/deactivation, the bindings and components, etc do not.
(I assume this is because they are stored in a container that is disposed on deactivation.)
The result is that upon every deactivation/activation of a view with a singleton view-model, the view is un-bound and then re-bound.
Is it possible to cause the bindings to persist across deactivation/activation?
This one stumped me for a good while. It also confused me as to why implementing it was not a higher priority for the Aurelia Team.
This takes a fair amount of code to get working. I have put the code in a Gist here: https://gist.github.com/Vaccano/1e862b9318f4f0a9a8e1176ff4fb727e
All the files are new ones except the last, which is a modification to your main.ts file. Also, all my code is in Typescript. If you are using Javascript you will have to translate it.
The basic idea behind it is that you cache the view and the view model. And your replace the router with a caching router. So when the user navigates back to your page, it checks first to see if there is a view/view model already created and uses that instead of making a new one.
NOTE: This is not "component" level code. That means I have tested that this works for the scenario that I use it for.
I got my start for making this change here: https://github.com/aurelia/router/issues/173 There is another user (Scapal) made something that works for him and posted it there. If what I am posting does not work for you, his may help you out.
i'm also interested in an answer to this.
maybe i'm now making a complete fool out of me but why not use aurelia-history navigate(..) command?
I wanna use minor upgrades, but I have two questions about the requirements for this type of upgrade.
Is it possible:
to remove a file(not KeyPath) from a component which is shared just in one existing feature (and after the removing the component is still not empty)?
to remove an existing component (I guess that it will violate the rules)?
Thanks for help!
to remove a file(not KeyPath) from a component which is shared just in
one existing feature
You can remove it from your upgraded package, but the update won't remove it on the target machine. A component is updated only if it's key path is changed: http://msdn.microsoft.com/en-us/library/windows/desktop/aa368599(v=vs.85).aspx
To remove it you can try using a custom action, but I'm not sure it will work. The best approach for removing resources when updating is using a major upgrade.
to remove an existing component (I guess that it will violate the
rules)?
If you remove a component it's no longer a minor upgrade. This falls into the major upgrade category.
It's possible, but it is not recommended. Changing the Component Code documents that addition or removal of files requires changing the component code. If you do not, What happens if the component rules are broken describes some of what can go wrong. Note that minor upgrades are often particularly picky about component rules.
Removing a component across a minor upgrade is also a no-no. Instead some people recommend marking that component as transitive and giving it a false condition to have it be removed during the minor upgrade. Note that component rules still apply to the component that only exists to be removed.
I see that some of the examples included with ExtJS 4 start up via a single call to Ext.application(). Other examples, however, manually call Ext.Loader.setConfig(), Ext.require(), and Ext.onReady() instead. I want to make sure I understand the difference.
Am I correct in assuming that:
you'd normally use the convenient Ext.application() call for a full-screen (e.g., Viewport-based) app?
if you just want to use a few ExtJS components on a pre-existing "non-Ext" page you'd opt for the manual calls to Ext.Loader, require, and onReady()?
Thanks for the clarification!
The full application call is used for the Ext MVC approach, and comes with a set of conventions to pre-load additional components, for example the stores and views options in the controller classes. For a better explanation see the Ext documentation on MVC.
If you just need to throw a few components on the page, as you state, you will get better performance just using the loader, or better, avoiding dynamic loading (at least in production).