I have a login page and a home page in my sample POC.
When user completed signed in, then i have redirect to home page from login page.
I have tried this below codes for redirecting to home page from login page using by angular.$location
Code 1
$location.path("/home");
This code is working good.No issues.
Code 2
$location.$$path="/home";
This code does not working probably, because the page is redirected, but URL is shown previous URL,does not changed the redirected URL.
Why is this happened?
What is the difference between code1 and code2
$$path is internal property of the angular you should not touch that.
if you see this code of location service in angular code base (https://github.com/angular/angular.js/blob/master/src/ng/location.js#L480).
$location.$$path = 'somepath', will only sets the $$path value
whereas,
$location.path('somepath') will do some other things also like calling $$compose internally and updating this.$$url and this.$$absUrl etc.
Angular uses a single dollar ($) for some of their API methods, properties, and event names. Those methods are considered "public" and safe to use by developers.
They are documented and not likely to change much, but if they do change then the angular team will tell us about it.
When you see two dollars ($$) then you're best off just leaving that alone. You can of course use them any way you want (debugging is a good use), but you shouldn't need to. If you use them for your own purposes there's no guarantee it will even be there on the next minor version update so your code becomes more brittle.
Related
I use a simple binary Vue variable named binary_state to control the class of an element, named "controlled_element" in the rest of this question. "controlled_element" has two classes "class_true" and "class_fasle" as determined by the value of binary_state. The value of binary_state itself switches between true and false using a button on the page. Let's call that button "controlling_element".
Every time the value of binary_state changes using "controlling_element", the updated value is sent to the server. On the other hand, every time the page is refreshed, an updated value for binary_state is retrieved from the server. Once that happens, the class of the "controlled_element" gets adjusted too.
It is a pretty straightforward scenario. Now consider the following steps:
Refresh the page, so a fresh value of binary_state gets retrieved from the server. For simplicity, let's assume the fresh value is true, i.e., binary_state=true. This will set the class of "controlled_element" to "class_true".
Press the "controlling_element" an odd number of times. This will set binary_state and the class of "controlled_element" to "false" and "class_false", respectively.
Navigate away from the page and come back to it using the back arrow (button) of the browser.
I expect the value of binary_state to continue to be false. That seems to be actually the case, as seen on the Vue devtool plugin.
I also expect the class of "controlled_element" to continue to be "class_false". However, to my surprise, the class is "class_true", which is the latest value received from the server regardless of all the changes that were applied in step 2.
Note that when navigating back to the page, the sync (reactivity) between binary_state and the class of "controlled_element" gets violated: As mentioned in step 4 above, the value of binary_state continues to be false (as indicated by the Vue devtool plugin), but the class of "controlled_element" is "class_true".
NOTE. I have seen this issue in chrome (Version 108.0.5359.125 (Official Build) (64-bit)) and Edge (108.0.1462.76 (Official build) (64-bit)), but everything is fine with Firefox (108.01.1 (64-bit)).
Three final remarks.
I have seen this related question. The author indicates they were able to solve the issue by setting autocomplete="on" of the form. I am not sure if that is helpful for me, because I do not have a form, to begin with.
I have seen some suggestions on using vuex or localStorage, but I am not sure if that is necessary in my case because, as mentioned in step 4, the Vue value binary_state seems to have the correct value.
I am not using vue-router if that has a bearing on this topic.
Well, to be honest, I have some suggestions depending on which version of vue you are using. For example, if you are using Vue2 or Vue3 with the cli, your state management problems can be solved with Vuex (however at this point vuex is not the officially recommended state management system anymore). The best solution, if you're using Vue3, is to go with Pinia https://pinia.vuejs.org which is very helpful, modern, and surprisingly easier to learn and use, compared to Vuex.
https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
localStorage is an alternate solution, but the tradeoff is that you will have to write code to erase that localStorage.
https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage
sessionStorage is similar to localStorage but will automatically erase the data after the window closes.
I solved the issue by manually reloading the page when a user visits the page using the browser back/forward buttons. The following code snippet does it:
<script>
if (performance) {
// get the PerformanceNavigationTiming object
const perfEntries = performance.getEntriesByType("navigation");
const perfNavTiming = perfEntries && perfEntries[0];
if (perfNavTiming) {
// get the type of navigation
const navType = perfNavTiming.type;
// reload if it is back_forward or prerender.
if ((navType === "back_forward") ||
(navType === "prerender")) {
window.location.reload();
}
}
}
</script>
It is not the neatest solution, but I guess I should go for it, given my time limit. I guess some learning is required before I can use the suggested solutions using localStorage, sessionStorage, and Piani, as I am not sure how to use these techniques to re-initiate the Vue two-way binding.
Preface: I have 1 day of experience playing around with React.
Using this source code from a tutorial, which is set up to login with google. https://github.com/The-Tech-Tutor/spring-react-login
I want to add the "Login with Paypal" button to the Login.js page.
This is what PayPal generates for me.
<span id='lippButton'></span>
<script src='https://www.paypalobjects.com/js/external/api.js'></script>
<script>
paypal.use( ['login'], function (login) {
login.render ({
"appid":"sdfgaesdfgrfed",
"scopes":"openid",
"containerid":"lippButton",
"responseType":"code",
"locale":"en-us",
"buttonType":"LWP",
"buttonShape":"pill",
"buttonSize":"lg",
"fullPage":"false",
"returnurl":"http://localhost:3000/profile"
});
});
</script>
How do I get this third party js to work with React?
Thank you.
I would recommend to take a look at https://developer.paypal.com/docs/log-in-with-paypal/ to get at least a deeper understanding what paypal is doing. I mean second day of react is may be a bit hard to integrate yourself, but as I can't assume your level of knowledge in general about web-dev (front + back) I think this is the way to go. From your code there is nothing suspicious only that you hopefully obfuscated your appId. Otherwise you need to create an appId in your Paypal-Account configure everything correctly (I guess especially the returnurl) and then use the provided appId.
If you only want to migrate the JS files to react look here: https://www.geeksforgeeks.org/how-to-include-an-external-javascript-library-to-reactjs/
I would take the last approach (document.createElement) as is it fully under your control to a certain extent, especially for debugging.
You could also write the whole loader and use implement the paypal.use call inside the react component by using the callback when the script is loaded an then access the paypal.use method.
My Shopify app replaces the product pages 'Add To Cart' form / product form, with it's own form of sorts. It is Liquid logic that decides whether or not to render the entire <form> element.
This works great, but on some themes (like Jumpstart by Shopify), the product page bugs out completely, throwing me an error saying:
option_selection.js - can't access its "parentNode" property
Which I believe is the option_selection.js function where it is looking for the select box / variant ID somewhere on the page.
Of course, this variant ID / select box does not exist because it is not being rendered.
How can I replace the add to cart form while satisfying the option_selection.js functions?
Usually this wouldn't be a big deal, but Shopify's app review team will give me problems with this, and on the Jumpstart theme specifically, this error causes the product photos to not render; breaking the page completely.
Any ideas here? Much appreciated!
Axing the entire product form seems a bit extreme - there's no way to do what you need to do in a less invasive way?
Assuming not, you'll want to expand your install so that you can update any code in a theme that initializes the product form to take into account the possibility that you've defied the theme's simplistic assumptions.
For the option_selection.js compatibility, you'll be looking for where new Shopify.OptionSelectors is being invoked. If your code has set a variable through Javascript, that may be the easiest check to make. Example of an inline install that assumes your code creates a function named MyAppNamespace.isProdHidden:
Original:
new Shopify.OptionSelectors( ...
Updated:
!(window.MyAppNamespace && MyAppNamespace.isProdHidden({{ product.id | json }}) ) && new Shopify.OptionSelectors( ...
The added piece of code will evaluate to false if and only if your app has loaded properly and your isProdHidden function returns a truthy value. This scenario would prevent the new Shopify.OptionSelectors part from running, since we're using the && as a sort of short-circuit/emergency-stop operation.
If your app failed to load (or was uninstalled from the store without the liquid code being updated), or if MyAppNamespace.isProdHidden returns false, then the added block of code evaluates as true and the new Shopify.OptionSelectors happens as normal.
The above is equivalent to wrapping the entire new Shopify.OptionSelectors call in an if statement, with the install benefit that the party installing your app doesn't need to read the theme code to figure out where the OptionSelectors call ends. In most themes the OptionSelectors code is spread out over multiple lines and occasionally theme developers declare their onVariantChange function as an inline anonymous function - neither of which are big obstacles for experienced developers, but a huge complication for novices and store owners without this kind of expertise.
Making the status of your app available somehow through Javascript is probably the best thing for you to do as far as theme-install-compatibility goes. Some themes have their OptionSelectors call right in the product page, which can be affected by dynamic Liquid variables, but many have this code tucked away in a .js file in the assets folder instead. Still other themes don't use Shopify's OptionSelectors code at all and instead run their own thing, and thus your app could interfere in completely unexpected ways or places. Creating tools to make it easier to integrate your app into somebody else's code is therefore one of the best things you can do.
You'll also want to make sure that your code is able to handle multiple products, as many stores have quick-shops all through the site which can load arbitrary product forms. By making sure you have made the tools available, it's possible for you, your support team (if any) and theme devs can make the required updates to (almost!) any arbitrary theme.
Hope that helps!
I'm trying to merge my Google Website Optimizer A/B testing with Google Analytics (in order to see how page variations affect stats like bounce rate, time on site, etc.). Eric Vasilik, who I believe works at GWO, recommends a technique for doing this that involves setting a user-defined GA variable that is dependent on what page variation the user has been shown. The description of his technique is here: http://www.gwotricks.com/2009/02/poor-mans-gwoanalytics-integration.html
Erik suggests calling the utmx() function on the "original" and "variation" pages in order to grab which page the user has been shown. But when I try doing this, it only works on the "original" page. This is because utmx() is undefined if the GWO control script has not been called, and that script only goes on the "original" page.
Am I missing something here? Since Erik works for GWO I'm sure he's right and I'm misunderstanding the technique, but I can't figure out what I'm doing wrong.
There is something missing here, and that is that the GwoTricks article you reference really only works for multi-variate GWO experiments. There is a way to make this work for GWO A/B experiments. I've updated the article to describe how one does this. But, briefly, the code which sets the user defined variable needs to be moved up from just before the tracking script to be between the two scripts which make up the A/B Control Script. This way, the user defined variable can be set before any redirection takes place so that the tracking script on the alternative pages will have the user defined variable set properly.
Mending a bug in our SAP BW web application, I need to call two javascript functions from the web framework library upon page load. The problem is that each of these functions reloads the page as a side-effect. In addition, I don't have access to modify these functions.
Any great ideas on how to execute a piece of code on "real" page load, then another piece of code on the subsequent load caused by this function, and then execute no code the third reload?
My best idea so far it to set a cookie on each go to determine what to run. I don't greatly love this solution. Anything better would be very welcome. And by the way, I do realize loading a page three times is absolutely ridiculous, but that's how we roll with SAP.
A cookie would work just fine. Or you could modify the query string each time with a "mode=x" or "load=x" parameter.
This would present a problem if the user tries to bookmark the final page, though. If that's an option, the cookie solution is fine. I would guess they need cookies enabled to get that far in the app anyway?
A cookie, or pass a query string parameter indicating which javascript function has been run. We had to do something along these lines to trip out a piece of our software. That's really the best I got.
Use a cookie or set a hidden field value. My vote would be for the field value.
This might be a cute case for using window.name, 'the property that survives page reloads'.