I'm learning so if this is a silly question feel free to let me know. My question relates to subscription and where you should subscribe. Let me be more specific with an example.
files
template.html
templatePieceOne.html
templatePieceTwo.html
In this example we have a template.html that will render using two separate template pieces. The template pieces might be used else where on the website. Is it better to subscribe at the top level template.html, template.js, or should the template pieces each have their own subscription.
If this doesn't make sense please let me know.
You definitely shouldn't subscribe in every template. Instead, you should decide which templates correspond to an independent part of the application, i.e. a view, modal or widget. Those templates should be responsible for subscribing to, managing and passing down their data.
This way you'll be able to see easily which part of the application is active at any given moment and what it subscribes to.
I recommend the following article on
presentation and container components.
Even if you're using Blaze instead of React the idea is still valid.
Related
I'm currently implementing a POC project in NextJs 12 to check whether it is possible for us to integrate it. I'm not able to update to 13 yet since I cannot support React 18 due to some in-house packages that we use, so for the purposes of this discussion let's pretend that Next 13 does not exist yet.
We all know that Next officially discourages the use of getInitialProps and recommends using getServerSideProps wherever possible. I'm aware of all the downsides of getInitialProps as opposed to getServerSideProps, main one being the constant client/server context switch which you have to be mindful of.
However, I cannot understand the easiness with which this is discouraged. Apart from NextJs itself I've seen a lot of blog posts calling it the worst thing ever and such. It seems to me like people who say stuff like that have not had some realistic use cases, and that the opinion mostly comes from toy projects (notes app, todo app, blog app etc).
Anyway the purpose of this question is twofold. One, to verify if it is at all possible in my case to avoid getInitialProps, and two, to see if anyone else thinks that this discouragement is somewhat unfounded and not based on reality.
The reason I've decided to use Next at all was to achieve SSR in React. The entire point of that, at least I believe so, is to enable SSR and still preserve some main benefits of React, such as a seamless SPA-like navigation in certain pages. If that was not the case I would have gone for a traditional SSR framework such as Ruby on Rails, Django, etc.
The reason why I need to use getInitialProps, and why I believe I cannot possibly avoid it, is based on two aspects:
Every single page that I have requires certain global data, which I don't want to refetch on every route.
The perfect example of this is the page header. The header of every one of my page depends on user data and translations (i18n). Both of these things I fetch from an external API. If I were to use GSSP then every route and every sub-route of every page would have to re-perform this data fetching which seems like a huge performance kill. I have no way to properly persist this data through GSSP navigation without conforming to some hacks such as sending hidden query parameters which check if data was already fetched. If we were to assume that the user always comes into contact with a page solely through its root URL, then this would work, but this assumption is extremely unrealistic.
By using getInitialProps in combination with redux and next-redux-wrapper, it is very easy to check if data was already fetched (even better if using RTKQ you don't even have to explicitly check it).
Big pages where I want SPA-like behaviour are not possible.
In my case I have one page which has about 5 sub-routes. On its homepage, we display a list of certain entities, which is fetched from the API. The API is such that entities can only be fetched as a list, and you cannot fetch entities individually. Then, for each entity, when you click on it, you can go to a sub-page where you see its specific info.
The only natural way to do this is to have the entire data fetched on the first page visit and then reused throughout the page as we navigate. Re-fetching the whole data on every page navigation is also a performance kill. The only way I was able to implement this and preserve a seamless SPA-like navigation was with getInitialProps.
What's interesting about this use case is that hacks with sending hidden query params would actually not do the trick, since even though I can force GSSP to be aware that the data is already fetched, I cannot access that data, therefore I cannot do any server-side route validation. What I mean is that if a user was to land on the home page, where all the entities are fetched, then somehow visit an entity page, like page/123, where an entity with id 123 does not exist, I cannot validate that and properly handle it in GSSP without re-fetching the entire list of entities again which is, once more, a performance kill.
So, in conclusion, I'd like to hear opinions on the discouragement of getInitialProps. For me it seems borderline impossible to completely migrate to getSeverSideProps if your app is at all realistic, uses translations, global data, etc.
Thanks in advance.
I am a little bit confused. How do we reuse areas from another page? Lets say I created an article in an articles area on my index page. How do I display that same content in another page?
Ive read the following https://documentation.magnolia-cms.com/display/DOCS53/Reusing+area+content
Seems kind of complex. I dont understand the pom file.
Cant we acccomplish this purely in light modules? If not, could someone show me an example of a simple content reuse scenario?
Yes you can do it purely w/ light modules. Look at this article. Example there is custom "quotation" app and the quotes you create you can render and reuse in as many different pages/page-types you want.
However it is slightly different than what you ask. In your question you want to reuse content from the page, which is also possible (you just need to address that content and feed it to appropriate cms tag in your page template (you can forget all about maven and so on, just focus on your templates). In the example I point you to, you create custom app for stories, articles or any kind of content and then just refer it from all pages where you want to render it. This allows you not only to share the content, but also separate it's editing from the page structure which makes life of editors easier in long run.
I have an use case in which I need to have multiple modules loaded in the view at the same time. Thing is, each of those modules might be as simple as a component, or a complex Angular module with a router and everything. I guess you could call it a plugable framework.
The number of modules I have to show or who they are is dynamic (I'm getting them from a server).
My first idea is that it would be good for this case if the feature module's router wouldn't be a singleton with the main one and also if they wouldn't update the url completly.
Each of the feature module should be able to be launched as a stand-alone app if bootstrapped (therefore, I do need it to be able incorporate all Angular 4 features including the router).
I managed to get something working by playing with the router and with named router outlets (secondary routes) but not sure how good that is in the long run.
How should I approach this?
I am in the early stages of attacking a somewhat similar scenario. In my app, the UI is organized in panels that are designed to stand alone on smaller displays, or side by side on larger. I find this approach works well for my routes, as my app is designed to edit a complex, highly hiegraphical document with many inter-related sections. e.g. User follows link on list to open detail, new detail panel appears to right... follows link on detail to related node... etc.
The solution I'm noodling with now is attempting to use an ngrx store that interacts with the router (and router-store) to dynamically create panels based upon router data. Well, technically it does not create the panels, it only serves the data that tells a component what to create and render.
I know my situ is not exactly the same as yours, but perhaps there's something in my approach that may help you find usefull or at least thought provoking.
Let's start with basic thing, simple example is Yii. It has such thing as widgets. Standalone, configurable and callable from any place we want classes. And I'm wondering can symfony2 has the same? What it will be? Controller in bundle? Action simple (method)? Widget (twig) with parameters?
In Yii we create class (of widget), standalone, describe it and use (by calling in template). How will it look like in symfony2?
Simple example 'i want create menu navigation using widget, where it will construct html by user roles'.
Symfony doesn't provide such a feature however you can make them yourself. They are few ways of doing it.
I'll just admit that we are talking about widgets that could do backend work (i.e. get data from DB, call an API, etc.).
1 - The scalable way
The use of the render tag in Twig which allows you to call a controller action from a template. It's scalable because you could use esi tags with Varnish (you can also implement your own caching profiles).
As a bonus, the profiler will show details about the specific render calls in the timeline (it will look like a subset of the entire request).
2 - Include a template
The included template gathers the data through a Twig function call. By experience, it's a bit faster than the first solution however it's not easily scalable.
3 - Render through a custom TwigExtension
The twig function will get the data and call the renderView method of the template service. If you are planning on doing this, you probably want to use the first method.
Conclusion
If you have a big website with modules/widgets that gets a lot of traffic (or "hit"): use the first solution.
If you have a small website with no support for caching: use the second solution. You'd use this solution if the module/widget is super light.
If you are thinking about the third solution... it's probably a good idea to use the first solution.
Personally, I'll always try to use the first solution and try to boost the performance one way or another. The render call in Twig has been significantly improved since the last versions of Symfony2.
Hopefully, my answer will provide you some guidelines.
Every tutorial/example i can find for meteor shows a single view application. I would like to build something a little more complex. I'm unclear how to approach multiple views...preferably in a way that's somewhat scalable?
The iron-router package lets you access different views (layouts) by nice, REST-ful human-friendly clean URLs. It supports parameters in the URL, "loading" templates, waiting for subscriptions to finish loading, before and after hooks etc.
At this point you can only create Single Page applications with Meteor. Note that Single Page, doesn't mean you can't have several views - use iron-router for that.
But by design, Meteor serves a big fat unique JavaScript/HTML/CSS application down to the browser, though there's a feature request to allow incremental loading. It is then up to the application (or more precisely, the JavaScript framework), to dynamically render its views in order to display different "pages".
I was wondering the same thing and it took me way too much time getting something started. I finally got a paged app working solidly by using Backbone views and routes, so I created a simple boilerplate project to make setting up an app like this easier in the future.
Live demo here: backbone-boilerplate.meteor.com
Source code here: github.com/justinmc/meteor-backbone-boilerplate
Have you looked at madewith.meteor.com?
A bunch of apps there have multiple views using Backbone also Jonathan Kingston who created britto has started simple meteor framework called Stellar
At this stage of the game not sure if there really are best practices. But these two seem to be the current flow.
You can also make a tabbed interface for multiple views. There is a package project "Smart package for generating a tabbed interface with pushState" github project here: https://github.com/possibilities/meteor-tabs
The best solution right now is using a routing package (router is basic but works). The workflow is something like this:
declare routes; return a template name for each route
place the reactive helper provided by the package in your body tag
the reactive helper will return the template associated to that route
you create a template for each route and optionally set custom publish functions
Router will give you browser history (client side).
Note that at this time there are some limitation on the way Meteor handles html/js. They are load all at the same time. The bright side is that once the app is loaded, page transitions will be instant.