I'm not sure if I'm doing something wrong, or if Mithril is. I have a route, say /admin/channels/edit/1. If I were to navigate to /admin/channels/edit/2 nothing is changed. As each route makes a request to an api no new data is requested from the api. I have the initial request being made in an oninit function. Shouldn't the new url force a new request?
Mithril is re-using the component instance since the routes are technically the same.
There's a useful section in the docs for ways to approach this issue: https://mithril.js.org/route.html#key-parameter
Here is my guess, you could manually call m.redraw() in your network call if you didn't use the default m.request() function.
Related
I added the routes dynamically to the router and I can visit all pages with router-view. However, when I try to refresh the page I cannot visit the page again although the URL is the same. It is http://localhost:8081/me.
this.$router.addRoute("Main", {
path: '/me',
name: 'Me',
component: () => import(`#/components/Me.vue`)
});
As I said, I can normally visit the page "Me", but when I refresh it, I cannot see its content anymore with the warning:
[Vue Router warn]: No match found for location with path "/me"
I tried to create router with createWebHistory("/") after reading the cause of the error but nothing seems to change. I will appreciate any help.
There are two reasons why this would happen.
First serving SPA application from the server.
Make sure that your back-end is set to serve index.html file for all routes since back-end server is unaware of the routes set by client-side router. Something like express-history-api-fallback-middleware can help is using Node.js/Express.js.
Second problem is that of using addRoute.
As you described, the problem could be that Vue router is taking routing decision before your code in components/common/LeftMenu.vue is getting executed which is responsible for calling addRoute(). Ensure that this code is called before routing decision is being made. Best way would be to move this logic in top-level application component. And, if you can move that to top-level components, that means you can try to declare all routes while defining the router.
Why that should be done?
Using addRoute is not necessarily an anti-pattern but having to rely on addRoute is often code smell. You would really need it in extremely rare scenarios. Routing is a high-level architectural concern for your application and thus better to be declared upfront somewhere at top-level module even before application is getting initialized. Low level components should not attempt to manipulate routing data structure (violation of DIP principles).
One scenario where you might be tempted to use addRoute is taking decision after some data manipulation by the component with addition of some API call. That seems legitimate need but then to address that there are better ways. Considering using route guards (guards support async resolution too!) and prevent user from entering the view till the guard is resolved successfully.
I'm getting my hands dirty with Node and expressJS, new with Node and ExpressJS, and there something that I can't get right.
There is a service that POST data (json format {}) to my "income" router, the thing is, a logger helper that check all routers is printing (console.log) the incoming data, but inside the router, I can't get anything (i can't do a console.log for example), not req.body, there is "nothing", just the res.sendStatus(200) that is required for (https://cloud.google.com/pubsub/docs/push).
Any idea about why this happens?
Thanks
There could possibly be some middlewares attached that are actually doing the job, while the router is merely printing the logs. In this case, middleware are attached to be functional well before the code in route gets executed.
Check for app.use or router.post('SOMEPATH',MIDDLEWARE1, MIDDLEWARE2)
ExpressJS's core strength is to modularise the code using middleware.
I've been trying to make use of service.getNavigation() method, but apparently the Request URI is too long which causes this error:
Request-URI Too Long
The requested URL's length exceeds the capacity limit for this server.
Is there a spartacus config that can resolve this issue?
Or is this supposed to be handled in the cloud (ccv2) config?
Not sure which service are you talking about specifically and what data are you passing there. For starters, please read this: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/414
Additionally it would benefit everyone if you could say something about the service you're using and the data you are trying to pass/get.
The navigation component is firing a request for all componentIds. If you have a navigation with a lot of (root?) elements, the maximum length of HTTP GET request might be too long for the given client or server.
The initial implementation of loading components was actually done by a POST request, but the impression was that we would not need to support requests with so many components. I guess we were wrong.
Luckily, the legacy POST based request is still in the code base, it's OccCmsComponentAdapter.findComponentsByIdsLegacy.
The easiest way for you to use this code, is to provide a CustomOccCmsComponentAdapter, that extends from OccCmsComponentAdapter. Then you can override the findComponentsByIds method and simply call the super.findComponentsByIdsLegacy and pass in a copy of the arguments.
A more cleaner way would be to override the CmsComponentConnector and directly delegate the load to the adapter.findComponentsByIdsLegacy. I would not start here, as it's more complicated. Do a POC with the first suggested approach.
I'm building an express app in express 4.0 (rc3), since I'm starting from scratch and in development for a while, but if there's a way to do this in 3.0, that'd be welcome too.
What I want is a set of comment REST routes that I can attach to other routes in my API. So:
/posts/:postID/comments/:commentID
/profiles/:profileID/comments/:commentID
The way I was doing it was to encapsulate the comment routes into a module, including a buildRoutes(router) function in the module.
Then I can do app.use('/api/comments', commentController.buildRoutes(express.Router())) in my main server definition, and then in my profile module's buildRoutes(router), I can do
buildRoutes = function(profileRouter)
.... build the basic CRUD routes ...
profileRouter.get('/:profileID', show)
profileRouter.use('/:profileID', commentController.buildRoutes(express.Router()))
It seems like only the .VERB methods actually replace :wildcards in the route, and not the .use one. I could always muddle through with a piece of custom middleware that goes on a /api/profiles/* and maps the appropriate URL parameters into req.fields, but I want to make sure that this is actually required.
So this wasn't particularly easy to do the way I originally intended. However, I just avoided the entire problem by reframing my buildRoutes method to accept a baseURL and a router argument. Instead of modularizing it completely, now I say, profileController.buildRoutes('/api/profiles/', router) which in turn calls commentController.buildRoutes('/api/profiles/:profileID/comments', router), and so on.
It's not terribly satisfying (I would rather encapsulate path/routing information and hide that from the controller) but it works.
I have a Restlet (v2.1.1) component that is using a ServerResource to process HTTP GET requests.
I would like to put filters and/or routers into the component so that they can do some processing before the request gets to the ServerResource.
I have been searching the Internet for an example of doing this, as well as reading the "Restlet in Action" book. I have discovered something interesting:
There are plenty of examples of how to set up a ServerResource within a component.
There are plenty of examples of how to create and set up filters and routers.
Unfortunately, search as I might, through the book and on the Internet, I cannot find an example of using both!
According to the book and the tutorials on the Internet, we should be able to create a component, set up a ServerResource in the component, and use a filter to preprocess requests that go to the ServerResource. None of the documentation anywhere seems to tell us exactly how to do this.
Am I misreading everything? Is there really no way to put filters or routers in components with ServerResources? Or have I missed some document somewhere that provides a real example of how to do this?
Could someone please either provide a simple example or provide a link to an example of doing this?
Thanks...
You need to attach the filter to the router and then attach the ServerResource to the filter using the method setNext(Class<? extends ServerResource> targetClass):
Filter myFilter = new MyFilter(getContext());
myFilter.setNext(MyServerResource.class);
router.attach("/test", myFilter);
Now you can preprocess using the filter's beforeHandle(Request request, Response response) method. If you return CONTINUE in this method, the filter will pass the request to the ServerResource.