This question already has answers here:
Mount react-admin under /admin
(4 answers)
Closed last year.
I am trying to integrate react-admin into an existing react app and am able to get the basic starter pages up and running , however, after adding a dummy resource and clicking on it in the UI, I am redirected to http://my-application.net/[resource name], which is incorrectly showing my applications error page.
I am trying to set up react admin in a sandbox-like scenario to avoid conflicts with some custom stuff I'm using for routing* and I currently have things set up to display react-admin under the /admin path in my app. Is it possible to tell react-admin to prefix all of its links (i.e. when clicking on a resource) with admin so that my app can correctly detect and route these pages to react-admin? For example, in the scenario from the last paragraph, when clicking on the dummy resource, i want it to direct me to http://my-application.net/admin/[resource name] instead of http://my-application.net/[resource name]
The closest I have been able to get is this SO post, which talks about adding admin/ as a prefix to the name of all resources. I have been able to make this work with some tweaks to my routing configuration to send all /admin pages to react-admin, but changing the resource names like this also has the side effect of changing them in the UI (i.e. my users resource appears as admin/users in the sidebar of react-admin)
Other things I looked at that didn't seem to be useful:
Using the customRoutes prop in <Admin>
<Resource>'s props seem to be intended more for tweaking the end of urls for different CRUD operations
this SO post seems like it might be about something different since this is the first mention ive seen of UrlField.
Does React-admin have an option to automatically add a baseUrl to all it's links?
* While not relevant for this question, the reason I am trying to do things this way is because my routing system (UniversalRouter, see here) is redux-based and appears to directly conflict with some of the redux state that react-admin needs according to the Using redux in a custom app tutorial.
An answer I found from a post the StackOverflow "related" sidebar seems to suggest that the history API has this kind of functionality:
The only other thing I can think of is properly configuring baseName in your history.
referring to this line in the OP's question (variable name changed for clarity):
const newHistory = createHistory({ basename: '/myadmin' });
Passing this modified history into react-admin's Admin component seems to achieve the intended behavior where clicking on resource links now correctly redirects to that resource underneath the specified baseURL.
<Admin ... history={newHistory} ...>
This is also mentioned in this other answer, which is way more concise than mine or the one i based this answer off of.
Related
I am building a react blog app, I am using a functional component where I will be using some internal and external links both. For the internal links I am using Link from react-router-domwhich is working fine but for the external link I am not able to decide will an Link from react-router-dom works, which directs to the path of the external URL or an <a> tag should be fine.
The purpose of using react-router-dom is to navigate to application routes by making changes in the DOM and not reloading the whole page. This scenario is applicable to internal links.
When coming towards external links. It is something that is not the part of our application. We cannot render it our application context. So, a solution to that is using an a tag for external links.
Link is basically a wrapper of an tag with a lot of upside functionalities like,
A can know when the route it links to is active and
automatically apply an activeClassName and/or activeStyle when given
either prop.
The will be active if the current route is either the linked
route or any descendant of the linked route.
To have the link be active only on the exact linked route, use
instead or set the onlyActiveOnIndex prop.
Read the rest at https://knowbody.github.io/react-router-docs/api/Link.html
You can use the anchor tag if you plain something plain. use Link for ease of use.
I'm using Next.js with Polaris (from following their guide here). Using Link component imported from either Polaris or Next.js is not updating the url in the embedded app.
While the url path doesn't change, the view does change correctly (i.e. the component for the new path does render). Same result with breadcrumbs and url prop for ResourceList.
Is this expected behavior?
Ended up figuring this out after many variations of trying to make links work correctly.
Answer: no, that's not expected behavior and links should change url path for Shopify embedded apps.
For Polaris, in order to make links change the URL you will need to install this library (#shopify/react-shopify-app-route-propagator). There is enough instructions on the page to figure out how to install it.
Important note on library usage: AppProvider had to be in the parent component for this.context.polaris.appBridge to work correctly. All the logic for context needed to be in a child component. This issue might've been unique to just my case, but maybe not.
How do I navigate to another page within my Elm application?
Specifically, I am trying to navigate from the Home page to the Contributor page.
The Contributor page is located under my Domain folder.
The file structure is below:
- Home.elm
- Domain
- Contributor.elm
I thought I could do something like this:
a [href "Domain/Contributor.elm"] [text "click me!"]
or this:
a [href "Domain/Contributor.html"] [text "click me!"]
However, neither of these paths work.
Note:
The app that I'm working on is NOT a SPA.
You are using elm-live, which is a development server. It targets a single Elm source file as its entry point, so unless your Elm code is built as a single page application, you won't be able to do any navigation to another file (though there is nothing wrong with hard-coding href links that link elsewhere).
elm-live is also only for development. You wouldn't want to run it on a production server.
If you are trying to avoid a SPA and would rather have each Elm file represent the complete functionality for a single page, perhaps you could go with the default functionality of elm make, which generates an HTML file that contains inline javascript compiled from Elm code. This is, in essence, what drives the elm-lang.org website. If you look at the source code, you'll see the html generated by the default elm make command, compiled against each Elm file "page" of the application.
On the other hand, if you are trying to build a SPA, #Bill's answer is a good starting point.
I don't believe you can do the sort of navigation you are trying to do within an Elm app without building a SPA. You are attempting to use the HTML href attribute to navigate. That attribute needs to be a real URL. Without using something like the Elm navigation package, you wont's have support for multiple routes.
Simple navigation in Elm is fairly straightforward. I wrote a blog post on this subject.
Also, here is the github repo that demonstrates the work in this post.
I have read this in many places "You will eventually want to create your own runtime directory and keep it in your own source repository...". Can anyone tell me how to do that? What if I don't want to lose some of the OOTB components?
Currently I am just planning to have a separate webapp for custom developed components. Let's say, I want to have "ootb" mount point for the OOTB components and blank "" mount point for custom developed components. How should I do that? This is what I have tried without success:
<webapp-list>
<webapp name="webroot" http-port="8080" https-enabled="false">
<root-screen host=".*/ootb" location="component://webroot/screen/webroot.xml"/>
</webapp>
<webapp name="customroot" http-port="8080" https-enabled="false">
<root-screen host=".*" location="component://customroot/screen/customroot.xml"/>
</webapp>
</webapp-list>
If this does not work then one other solution that I can think of is to just have the "customroot" entry, and add the "webroot" as SubScreenItem in it. The "customroot" screen will just be blank, and my custom decorator will be present in the "customapps" screen which will be a counter part of the "apps" screen. And all my screens will use the "customapps" screen.
Although I haven't tried what I wrote above, but that somehow feels like a hack. I believe there should be some better way to do this.
And yes, I have read the article, I want to use localhost and there should be some way to do it with localhost too.
As explained in the other StackOverflow question you linked to (on the word "article") the webapp element used at runtime is selected based on the "moqui-name" context-param from the web.xml file for the webapp (in or out of a WAR file). Unless you are deploying multiple WAR files or other forms of webapps this is not useful.
What you are describing would be handled by adding subscreens in the screen hierarchy at the desired points. The general idea with the screen hierarchy in Moqui is that you can have root screens of "applications" mounted through various means (see the annotations on the subscreens element or the Making Apps with Moqui book for details on the 3 ways of doing this). Part of the point of this is to AVOID multiple webapps mounted in the servlet container because that makes things more complicated, including: handling authc and sessions, configuration and deployment, and so on.
Generally for an application in a component you'll want to use a database record to add a subscreen to an existing screen in the hierarchy, mainly from the "webroot" component. Here is an example of that from the example app in Moqui (this adds an "example" path elements under the "apps" path element, where the apps.xml screen is mounted under the root screen, putting it at /apps/example):
<moqui.screen.SubscreensItem screenLocation="component://webroot/screen/webroot/apps.xml"
subscreenName="example" userGroupId="ALL_USERS" menuTitle="Example" menuIndex="8" menuInclude="Y"
subscreenLocation="component://example/screen/ExampleApp.xml"/>
Here is an example from PopCommerce to mount the root screen of the application under the root screen instead of the "apps" screen (i.e. making it located at /popc instead of /apps/popc; note that this means the decoration in the apps.xml screen will not be used because it's not in the render path):
<moqui.screen.SubscreensItem screenLocation="component://webroot/screen/webroot.xml"
subscreenName="popc" userGroupId="ALL_USERS" menuTitle="POP Commerce" menuIndex="9" menuInclude="N"
subscreenLocation="component://PopCommerce/screen/PopCommerceRoot.xml"/>
I think I might have asked a confusing question, but thanks for your time David. If I try to rephrase my question, it would be: "How to have a decorator screen which will not use any HTML from the webroot or apps screens?"
I think I found the answer. I just added my customroot screen as SubScreenItem under webroot screen, and mentioned the attribute standalone="true" in it. Now my URL: localhost:8080/customroot/foo does not use anything mentioned in webroot or apps screens.
Just that, now if I want to have all my components to be at root level in URL like: localhost:8080/foo
I think the only way to do that would be to shift the OOTB components to some other URL like: localhost:8080/ootb/apps/AppList
To do that I will have to add webroot as SubScreenItem of the customroot screen, and replace the webapp entry of webroot with that of customroot.
Damn, I tried so hard and it still is confusing.
I'm creating a SPA app using Durandal and I would like to include a credit card payment facility. The guys that I'm looking at requires you to give return URLs to success, cancel and a view other pages, is that possible?
To me it would be breaking the 'single page' part of SPA, but is it possible? Could I do it all in a window?
Disclaimer: I don't know Durandal, but you would solve this in an SPA using either "hashbang URIs" or actually re-serving the SPA in your webserver for the requested return URI and adjusting the content using the same technique as hangbash URIs but using history.pushstate/history.popstate instead, see here: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history
A more general article from Google is available here that covers the same principle: https://developers.google.com/webmasters/ajax-crawling/
This "works" because SPAs are SPAs only in that the browser requests a new HTML document from the server once (or in your case, twice), the SPA should still be updating the history and address-bar state of the UA as the user navigates the application, just as though it were a regular multi-page application.
A great example of this is GitHub's source navigator: Try here ( https://github.com/angular/angular.js ) and navigate the repository, observe that the contents of the file-listing change as does the address bar, but your browser doesn't reload the whole page... yet if you copy+paste the (modified) address bar address into a new browser window, you get the same page back.
I looked into doing credit card processing from a SPA and the best option I had found was Stripe. They supply a javascript file that looks like it would work, I never implemented it on my project due to time constraints so I can't confirm that it works but it looked very promising.
IFRAMEs are quite good for this sort of thing. You can use jQuery to hook an event handler to the page load event and this will tell you when the other end has responded. Load the 3rd party page into the IFRAME and serve response pages on the URLs you provide to the service provider. As mentioned by others you can use routes to identify the response pages. The IFRAME will stop the round-tripping from mucking up your application state and in fact it is possible to put script in your response pages that dot-notates its merry way up the DOM and into your app.