How many components can be cached using Vue keep-alive? - caching

I'm using keep-alive in the router-view like this:
<keep-alive>
<router-view></router-view>
<keep-alive>
So I'm saving all "pages" of my app. My questions:
How many components can keep-alive save?
Can I program something to make keep-alive save just one component (the last one)?
Thanks in advance

I found a solution for my problem using the sugestion of #zizzo. I saved in the vuex the component that I wanted to save when I want to save (the last one). The code stayed like this:
<keep-alive :include="[componentToKeepAlive.name]">
<router-view></router-view>
<keep-alive>
...mapGetters({
componentToKeepAlive: 'global/componentToKeepAlive'
})

Related

Livewire child component freezes parent component once refreshed

I have a simple ExpenseShow component that has a child ExpenseForm component.
On ExpenseShow I have a simple update button:
<x-cards. Button
wire:click"$emitTo('expenses. Expense-form', 'editExpense', {{$expense->id}})"
>
Edit Expense
</x-cards. Button>
...
#livewire('expenses.expense-new-form')
The click of the button emits the editExpense event, which opens a modal and the expense is Updated as expected. Then I emit back to $this->emitTo('expenses.expense-show', 'refreshComponent'); from the child component (update method on `ExpenseForm') and it freezes my page (parent component after modal goes away and database is updated.) for a couple of seconds.
However, when I use wire.poll on the ExpenseShow component in the blade everything updates fine with no delay. I just think it's wasteful for this scenario. I don't need the server running requests every 2 seconds, that's why I think refreshComponent is more applicable here. Any ideas? My ExpenseForm has a few dropdowns with hundreds of entries each but wire:poll has no delay and it does it nonstop.
Thanks for any input. Patryk.
Edit:
There was an answer here that made sense. It looks like he deleted his answer. I meant to mark it as Answered when I implemented one of the options. I hope that nice user showa it again. In a nutshell, he suggested I bind my parent and child components via wire: model or that I use livewire: loading or something about livewire: on to replace my on: click and emit... can anyone fill in the gaps? Not sure why their answer was deleted...
Wow. When I wrote this post both Chrome and Edge browsers experienced both issues. Since then, Chrome has been updated and I was able to achieve my desired result per livewire docs ( refresh Component ), shortly after it looks like Microsoft Edge is also working!

VeeValidate does not update if input/textbox set with jQuery

Go here (Chrome seems to work best for this example):
https://jsfiddle.net/gongzza/m67d8f4x/2/
Type a#b.com into the input. Notice how the error goes away. Now clear the input.
In the console, programmatically set the value of the email with:
$('[name=email]').value = 'a#b.com'
Notice how the input changes but the validation does not get refreshed.
My recommendation is that you should use Vue to manipulate the values of these things. The only reason I can imagine you're trying to use jQuery here is because you're doing it from outside the Vue app. Given that, you would be better served to do this:
$('#app').__vue__.email = 'a#b.com'
That way Vue will notice the change and do it's own event handling. I'm not sure there's a more "official" way to access the Vue data, but this is the way I've done it before.

Change content view of Laravel layout without page refresh

I've been searching for an hour on how to nagivate within my Laravel website without refreshing the website (page layout), but I couldn't find a proper solution: one that not just loads the HTML, but actually replaces the content view within the layout.
This is my current dashboard:
So when clicking on a menu item within the blue area, I want the red content area to change without page refresh. What would be a scalable solution for this? I'm trying to follow the DRY (Don't repeat yourself) principle as much as possible.
Oh, please don't mark this topic as a clone of other topics as I've seen most of them but without proper solution. Hope anyone can help me out.
Changing a view without page load means we need to use the ajax techology. Vuejs is a frontend frameework the allows us to acomplish that easily with its axios library
I believe you can get this done by using jQuery load function -
$(function () {
$("#menu_option_a").on("click", function () {
$("#dashboard").load("View1.html");
});
$("#menu_option_b").on("click", function () {
$("#dashboard").load("View2.html");
});
});

JSF Ajax - trigger on partially completed field

I want to implement a "typeahead" type of functionality but for effiency reasons to avoid return a list of possibly thousands of entries, I only want to fire the request to the server when the user has entered at least three characters. I.E. on the 3rd keypress, I want to call my server side search via ajax.
I'm not looking for a full runnable example, just a sketch of how this might be possible, as I'm a bit stumped by it.
I do have a generic ajax handler js file in my app to render the ajax "spinner" so I thought I might be able to hook into event method for status="begin" and somehow abort the request if the input field has less than 3 characters but I don't see how that's possible.
I'm hoping a certain JSF guru might be able to point me in the right direction :)
I'm using standard reference JSF2, no 3rd party libraries...
How about adding a onkeyup="myFunction(event)" to your input
<input type="text" onkeyup="myFunction(event)">
and in js add the following
function myFunction(e){
if (e.target.value && e.target.value.length > 2) {
alert('do some ajax with the value: ' + e.target.value);
}
}
In jsf you can add some hidden input with f:ajax and trigger it from js with somethign like this document.getElementById("myButtonId").click();
Online example

Why doesn't Firefox show the correct default select option?

I'm making a web app to manage product SKUS. One part of that is to associate SKUs with product names. On each row of a table, I list a SKU and display a <select> box with product names. The product that's currently associated with that SKU in the database is given an attribute like selected="selected". This can be changed and updated via AJAX.
There are a lot of product <option>s - 103 to be exact - and this list is repeated in the <select> on each row.
From another input on the page, I am using jQuery AJAX requests to add new SKU/product associations, and to make it clear that they're added instantly, I insert them into the top of the table with a little highlight effect. As the number of SKUs increases past 10 or so, if I refresh the page (which loads everything back out of the database ordered by product name), Firefox starts to show some wrong options as selected by default. It is not consistent about which incorrect option it shows, but it seems to be mixing up the options that existed before the page reload.
If I inspect the <select> using Firebug, the select="selected" is on the correct <option> tag. Refreshing the page (or leaving and typing this page's URL back in to return) does not make it show up correctly, but hard refreshing (Ctrl+F5) does.
Both Chrome and IE7 display this correctly in the first place.
My theory is that this is a result of a faulty cache strategy by Firefox. Does that sound right? Is there any way I can say in my code "if this page is refreshed, make it a hard refresh - reload everything from scratch?"
Update
To solve this problem, I changed strategies.
Previously, I put a <select> with a long list of <option>s on each table row, with the current value set as default
Now, I put the current value in a <span>. If the user clicks a "change" button, I replace the <span> with a <select>, and the "change" button becomes a "confirm" button. If they change options and click confirm, AJAX updates the database, the and the <select> goes back to being a <span>, this time with the new value.
This has two benefits:
It fixes the bug described above
It requires far fewer DOM elements on the page (all those redundant <option>s)
I had a similar problem, but after adding autocomplete="off" HTML attribute to every select tag it worked. [I was using Firefox 8]
Firefox preserves your selected form elements when you refresh. It's intentional. Ctrl+F5 is a "hard" refresh, which disables this behavior.
--
Or Command+Shift+R if you are on a Mac
An easy way to prevent Firefox from caching the last selected option is to remove all of the option elements on page unload. For example (assuming jQuery):
$(window).unload(function() {
$('select option').remove();
});
I had this same issue. I was trying to change the value of the select depending on which option had selected="selected", but Firefox wasn't working. It would always default to the first option.
Chrome, Safari, etc worked when I did this:
$( 'option[value="myVal"]' ).attr( 'selected', 'selected' );
... but this wasn't working in FF.
So I tried:
$( 'option[value="myVal"]' ).prop( 'selected', 'selected' );
and it works.
jQuery v1.9.1
Although this is old question, but below solution can help someone
In firefox, I've notice that the "selected" attribute will not work unless you place the select inside a form, where the form has a name attribute.
<form name="test_form" method="POST">
<select name="city">
<option value="1">Test</option>
<option selected="selected" value="2">Test2</option>
</selecct>
Again remember :
form must have the "name" attribute and
"select" must be inside the form.
I make it worked by putting the autocomplete="off" on the hidden input.
Firebug has a cache disable function for exactly this scenario.
The deeper long-term solution is to work out how set no-cache headers server side. What web server are you using?
Every time I ever had weird select option bugs in Firefox it was because I had multiple options marked as selected. Are you quite sure that only one is marked as such? Seems like you could get out of wack pretty easily if you are changing that with AJAX.
FYI: in order to stop Firefox from restoring the previously selected option after page reload you can place the entire <form> containing the <select> options inside an <iframe>.
When select boxes are in <iframe> and you reload the container page, Firefox finally behaves like ALL other browsers, by simply resetting select options.
Thanks to #BananaDeveloper (https://stackoverflow.com/a/8258154/2182349) - this is my solution to solve this problem on a single page in an application
I didn't want to customize the off-the-shelf/open source application code
<Files "page_that_does_not_work.php">
SetOutputFilter INFLATE;SUBSTITUTE;DEFLATE
Substitute 's/<select/<select autocomplete="off"/n'
Substitute 's/<form/<form novalidate/n'
</Files>
Apache docs for mod_substitute https://httpd.apache.org/docs/2.4/mod/mod_substitute.html
Thanks to: https://serverfault.com/questions/843905/apache-mod-substitute-works-in-curl-but-not-on-browser for the SetOutputFilter
Replacing jQuery
.attr('selected', true)
with
.prop('selected', true)
for <option> tag fixes it for me. All other solutions didn't work
I've figured out. If you put onunload or $(window).unload (jquery) on your HTML with no-cache header, Firefox reloads the page and initialize DOM even from back button.

Resources