can you please give me a hand with Deep Linking. When I work in a development environment it works for me with the URL: exp://192.168.100.4:19000/--/resetPassword/rzBsP3tJ, however, when I publish it, I open it with the URL: exp://exp.host/#user/#nameApp/--/resetPassword/rzBsP3tJ?release-channel=testing, it just opens the app, but it doesn't redirect me to the screen I want. What I can do?
An assumption here: you talk about screens so assuming you are using react-navigation and making use of LinkingOptions.
The issue is caused by a mismatch between how Expo defines a linking URL and how react-navigation defines LinkingOptions. LinkingOptions is in terms of a path, not a URL that has any query params. In development there are no query params, but an app that is is published to a channel has the 'release-channel' query param so this will never match in react-navigation's LinkingOptions.
The solution is just to remove the release-channel query param from the URL returned by Linking.createURL:
import * as Linking from 'expo-linking';
import { URL } from 'react-native-url-polyfill';
const urlWithReleaseChannel = Linking.createURL('/')
const parsedUrl = new URL(urlWithReleaseChannel)
parsedUrl.searchParams.delete("release-channel")
export const resetLinkingOptions = {
prefixes: [parsedUrl.toString()],
config: {
screens: {
ResetPassword: {
path: 'resetPassword/:id'
}
}
}
}
This works for both development and deployed apps: if present, release-channel then behaves as a regular query param. Note that react-native-url-polyfill is required as a project dependency as out of the box the RN URL is not fully featured and lacks in this case the ability to delete a query param.
Related
To have specific layout for some pages at our project we create few custom PageLayoutComponent's. Some contfiguration example:
{
// #ts-ignore
path: null,
canActivate: [CmsPageGuard],
component: CartPageLayoutComponent,
data: {
cxRoute: 'cart',
cxContext: {
[ORDER_ENTRIES_CONTEXT]: ActiveCartOrderEntriesContextToken,
},
},
},
All work fine with storefront until you will not try to select specific page at smartedit. As result it not use our custom CartPageLayoutComponent, but will use PageLayoutComponent for rendering.
Probably this is because it's not a normal route navigation. Can somebody from spartacus team suggest how this bug can be fixed?
Probably this is because it's not a normal route navigation
I believe your Route should be recognized normally, there is nothing special in adding a custom Angular Route.
So I guess there is something special about the page or URL of Spartacus Storefront that runs in your SmartEdit.
It's hard to tell the reason of your problem without more debugging.
You said your app works as expected when run differently (locally?), but when used in SmartEdit, then there is a problem. Please identify factors that makes the run SmartEdit different from your (local?) run. And try to isolate them. Guesses from top of my head:
production vs dev mode of the build?
exact URL of the cart page?
any difference in configuration between a local version and deployed one to be used in SmartEdit?
I would also add some debugging code to better know which routes configs are available and which one is used for the current route. For debugging purposes please add the following constructor logic in your AppModule:
export class AppModule {
// on every page change, log:
// - active url
// - the Route object that was matched with the active URL
// - all the Route objects provided to Angular Router
constructor(router: Router) {
router.events.subscribe((event) => {
if (event instanceof NavigationEnd) {
console.log({
activeUrl: router.url,
activeRouteConfig:
router.routerState.snapshot.root.firstChild.routeConfig,
allRoutesConfigs: router.config,
});
}
});
}
}
The pages opened in SmartEdit have the same route of cx-preview (e.g. to open faq page in smartedit, request is https://localhost:4200/electronics-spa/en/USD/cx-preview?cmsTicketId=xxxxx. backend can get page id from cmsTicketId). If you want to change the page layout, you can consider use PageLayoutHandler. Spartacus has some PageLayoutHandlers, e.g.
{
provide: PAGE_LAYOUT_HANDLER,
useExisting: CartPageLayoutHandler,
multi: true,
},
I'm setting up a simple React Native learning app for several students on Expo, that also talks to an API server the student is learning to code.
The student's API server is run via node server.js, and serves on localhost:3000 on the student's machine. It has nothing to do with expo.
I want students to be able to run their app via any of expo start --android, expo start --ios, or expo start --web, on the same machine that runs their API server. Each student runs from home on a different home wifi network, and doesn't necessarily know the ins and outs of ip addresses or networking.
When using expo start --web, we get CORS exceptions, unless we use the custom webpack.config.js work around (first create webpack.config.js via https://docs.expo.io/guides/customizing-webpack/, then put this in webpack.config.js):
const createExpoWebpackConfigAsync = require('#expo/webpack-config');
module.exports = async function(env, argv) {
const config = await createExpoWebpackConfigAsync(env, argv);
if (config.mode === 'development') {
config.devServer.proxy = {
'/**': {
target: {
host: 'localhost',
protocol: 'http:',
port: 3000,
},
secure: false,
changeOrigin: true,
logLevel: 'info',
},
};
}
return config;
};
This is great, because we can make api calls to ./end/point without knowing the student's ip address, and the webpack devServer launched by expo-cli effectively proxies around to http://localhost:3000/end/point on the student's development machine.
Meanwhile, for iOS and Android, I've found this snippet:
import Constants from "expo-constants";
const { manifest } = Constants;
const SERVER_URL = "http://"+manifest.debuggerHost.split(`:`).shift().concat(`:3000`)+"/";
and then using SERVER_URL when using fetch().
But, we're missing a unified solution that works agnostic of which environment we're in (web, ios, or android). The webpack proxy only appears to be on and work when using the expo web client (expo-cli doesn't launch webpack for ios or android), and the 2nd option (A) doesn't work out of the box on web and (B) would trigger a CORS exception anyway.
How can I elegantly write one bit of code, or otherwise set up the project for the students, so that (A) they don't need to know their dev machine's ip address, or what that means and (B) it will work regardless of whether they're in the web, android, or ios expo client?
Don't like this as an answer and would prefer someone who knows better to point out better, but this is what I ended up using that seems to work, at least in development:
// Some chatter that Contants.manifest needs to come from a different package?
import Constants from "expo-constants";
const { manifest } = Constants;
const SERVER_URL = (() => {
// TODO - put a "prod" api server somewhere
// Android / IOS - no CORS issue.
if (!!manifest.debuggerHost) {
return "http://"+manifest.debuggerHost.split(`:`).shift().concat(`:3000/`);
}
// Expo Web client, making use of webpack.config.js (see original question) for devServer proxy.
else {
return "./";
}
})();
...
fetch(SERVER_URL + 'some_endpoint/').then(...)
I created a plugin injecting a noty (https://ned.im/noty/#/) so I can use it globally, it looks like this:
export default ({ app }, inject) => {
const notify = function (options = {}) {
if (process.client) {
new Noty(options).show();
}
}
app.$notify = notify;
inject('notify', notify);
}
This plugin shows a noty only on the client-side. On the server-side a noty does not appear, cause it can be displayed only in browser.
I have a page with product details and I am receiving data in asyncData method. When the product was not found I would like to show a noty with proper message and redirect user to a product list page. When I change a route in client-side everything works awesome. However on the first page load (eg. I change an url manually in the browser) which happens on the server-side a noty does not appear, only a redirect works.
My question is: how to show a noty in this case? How to create a noty in the browser after SSR or what is the best other solution to my problem?
Is there any way to run some code after client-side is already rendered (after server-side-rendering)?
You could just disable ssr for that plugin.
plugins: [
...,
{ src: '~plugins/yourplugin.js', ssr: false }
]
Okay, I found a module for that: https://github.com/potato4d/nuxt-client-init-module
it's not possible right know (nuxt <= 2.14.0 when i answering)
but you can combine client plugin and client middleware to achieve that
please take a look at this link:
https://github.com/nuxt/nuxt.js/issues/2653#issuecomment-390588837
Background
I am using expo to view my react native app on my android phone. I have implemented a node server that the app retrieves data from. To retrieve data I am using the library redux-api-middleware and storing it in the redux store.
I have used this setup before with regular react apps but not react-native.
Problem
When I switch the app from develop to production mode in expo my calls to the server no longer work. I get the following response instead of the data like in dev mode.
Object {
"error": true,
"payload": [InvalidRSAA: Invalid RSAA],
"type": Symbol {
"_k": "Symbol(REQUEST_TEST_REQ)_l.b74uhq9lvf",
},
}
My Current Call
import { RSAA } from 'redux-api-middleware';
import { NODE_API_URL } from 'react-native-dotenv';
export const REQUEST_TEST_REQ = Symbol('REQUEST_TEST_REQ');
export const REQUEST_TEST_SUC = Symbol('REQUEST_TEST_SUC');
export const REQUEST_TEST_FAIL = Symbol('REQUEST_TEST_FAIL');
const requestSomeDataFromTheServer = () => {
return {
[RSAA]: {
endpoint: `${NODE_API_URL}/api/test`,
method: 'POST',
headers: {
'Accept': 'application/json',
'Content-Type': 'application/json'
},
types: [
REQUEST_TEST_REQ,
REQUEST_TEST_SUC,
REQUEST_TEST_FAIL
]
}
}
};
export { requestSomeDataFromTheServer };
Question
So I follow the rules of the RSAA request but I see this failure as soon as a request is made. It is definitely not my node server since it works in dev mode. Can someone shed some light on this issue for me?
Symbols create invalid requests in production mode
I thought that maybe it was a problem with fetch in production so I added a polyfill first but this didn't help. This gave me the idea to take everything back to basics and so i turned the symbols into strings.
export const REQUEST_TEST_REQ = 'REQUEST_TEST_REQ';
export const REQUEST_TEST_SUC = 'REQUEST_TEST_SUC';
export const REQUEST_TEST_FAIL = 'REQUEST_TEST_FAIL';
By changing these back to plain strings the request is valid and so my problem is solved.
I am still unaware as to why the symbols break in production mode because they work fine in the develop. Also I am using babel polyfill to make them "safe" to use.
If anyone could clear up the rest of this mystery that would be great.
We're doing this in the web version of our react application and our native Android app so our setup and everything is working fine. I'm trying to implement sharing an action in react-native using react-native-fbsdk. I'm following the Android code because it looks the closest to the react-native-fbsdk code.
Should I be using ShareApi.share or something else?
I tried creating an instance of ShareOpenGraphContent to use with ShareApi.share, but there's no constructor.
I wish they would provide more thorough documentation :s
Based on the code my colleague used for the ShareApi on Android it seems like react-native-fbsdk is missing a few things related to sharing actions.
ShareOpenGraphContent isn't directly exported from react-native-fbsdk so this
import { ShareOpenGraphContent } from 'react-native-fbsdk';
Actually doesn't work. There must be some way to use the ShareApi in react-native-fbsdk to share an action...I'm just missing something.
Someone help...please.
Thanks!!
I figured it out! I had to manually create an instance of the ShareOpenGraphContent object which has 3 mandatory properties: contentType, action and previewPropertyName. The react-native-fbsdk doesn't currently have a constructor for this object type.
ShareApi.canShare isn't mandatory, but it checks to ensure you have the correct permissions before trying to share. This would allow you to get the user logged in before trying in case their token expired, or the user hasn't agreed to the needed permissions yet.
const ogAction = new ShareOpenGraphAction('<your_facebook_namespace>' + ':' + '<your_facebook_action>');
ogAction.putString('song', 'https://<url_to_your_song_app_etc>');
ogAction.putString('place', '<fbPlacePageID>'');
ogAction.putNumber('fb:explicitly_shared', 1); // Normally this is a boolean, but putNumber with a value of 1 works
// Manually create an instance of ShareOpenGraphContent (no constructor in the API)
const ogContent = {
contentType: 'open-graph',
action: ogAction,
previewPropertyName: 'song',
};
ShareApi.canShare(ogContent).then((canShare) => {
if (canShare)
return ShareApi.share(ogContent, '/me');
}).then(
function(result) {
// Shared successfully
},
function(error) {
// Failed to share
}
);