Difference google analytics object and dataLayer in React.js - reactjs

I have in my .env fiel the field
REACT_APP_MEASUREMENT_ID=G-XXXXXXXX
I am using react-gtm-module and Google Tag Manager 4 (and still also Universal analytics) and I initialize in my App.js:
useEffect(() => {
TagManager.initialize({ gtmId: 'GTM-XXXXXX' });
analytics.logEvent('screen_view', {
firebase_screen: 'Home',
firebase_screen_class: 'MainPage',
})
}, [analytics])
However, the analytics object comes from firebase.analytics(app) that I initialized in the firebase.js file... has that analytics object from fire/analytics anything to do with the google tag manager or the datalayer object, or with google analytics at all or is that something different?
I am using that analytics object in my components just as the datalayer object, and it also gives me the same kind ob datalayer object in google tagassistant, e.g:
setGameFinished(gameFinished => (gameFinished = true))
analytics.logEvent('game_finished', {
score: `${correctAnswerCount} of ${quizData.length}`,
})
gives me dataLayer.push({event: "game_finished", eventModel: {score: "2 of 4", send_to: ""}, gtm.uniqueEventId: 23}) in google analytics tagassistant (debug window).
But is it the same? I think I might have messed something up there ;). Can someone explain me the difference?

Difference between Firebase and GTM? First of all, Firebase is an SDK. To be used in native apps. JS-driven apps (except react native, I believe) are supposed to use gtag.js. Gtag is a way to track data directly to GA4. And for Universal analytics, they use the analytics.js lib.
So, again:
Firebase SDK was meant to track apps and that data goes to the Firebase service. Soon after introducing firebase, Google realized it wasn't a very comfortable thing to use, so they rolled out GA4 with a very similar to Firebase data model, and since the data model is so close, they made it easy to sync Firebase instance with a GA4 instance. Also, they decided not to bother with a new SDK for the native apps and went with firebase for ga4.
Google Analytics (a slightly different thing from firebase) has had its history of bad architectures as well, but now we have two analytics libraries, analytics.js that is meant to be deprecated in a year or so with Universal Analytics and ga4 that is meant to replace it despite all the bugs it brings. Ga4 uses the gtag.js lib. But that's only for web. This will only work in apps that allow unsecure external scripts execution, so, like, browsers. Electron-driven apps, too.
Firebase SDK allows you to send events directly to your Firebase endpoint and that makes the data available for analysis or further ETL.
Now, GTM, unlike the other libs, is not meant to just send the payloads to the endpoint. It's meant to add a middle man. Basically, GTM deploys a collection of user logic, so in GTM users can grab whatever you're pushing in the dataLayer array, rearrange it, change it and send it to wherever. And wherever can be anything, it can be ga4, can be ga ua, can be facebook or any other endpoint. GTM, as any other tag management system ultimately executes custom javascript on pages where it's loaded.
There's also GTM for native apps. And that thing is largely useless. It can't really do anything and requires being loaded on every build. It also loses the ability to execute code, so no hotfixing or independent tracking implementation is not possible. Honestly, mobile GTM is about as helpful as the GTM loaded within the no script tag. Native GTM does not provide enough use to justify the spread of business logic and added dependency. It was made just so that Google could claim that it's cross-platform. Same about the no-script: just for the company to be able to claim that it doesn't depend on JS completely.
Good, now that we're done with the context of what's happening, if you're using react for front-end, then you don't need anything except GTM. GTM is able to load all the libraries it needs for tracking without your intervention and send events as needed, but someone needs to build logic in GTM for whatever is being pushed to the DL. You don't need firebase, having GTM (dataLayer) as the only touchpoint between analytics and front-end is the best practice.
If you're doing react native for a native app, then it's the opposite - you likely don't need GTM. But sync with your implementation specialists or whoever owns the GTM account in the company.

Related

Pre-rendering with Rehydration (PRH)

I'm working on a project, which has two applications, one is an admin portal where users can customize and create their profile and other one is an application which will preview the profile user creates.
All good with the admin portal, which is developed with CRA - React App. Earlier I was planning creating profile app also with React. Anyhow considering SEO and performance I'm thinking about pre-rendering the profile whenever user changes data.
This will improve the performance by considerable margin and SEO as well. SSR is another good solution, however when there are thousands/millinos of users view single profile, there will be a huge demand for server performance. So that I'm planning to work on a POC, which will create static profile with partial cliend side js functionalities for each user and store it somewhere and serve it through CDN.
I want to know two things here -
To implement this, I'm having lack of knowledge in terms of available solutions. Solutions for storage, cdn.
How can we render static pages during the data changes.
To implement this, I'm having lack of knowledge in terms of available
solutions. Solutions for storage, cdn.
Check Cloudflare CDN. But there are many other proveriders.
How can we render static pages during the data changes.
If you are using pre-rendering, You can rebuild the page assets after a profile page is updated and redeploy them.
If you are using SSR then the server load will be high but no need to redeploy (as the page is rendered at runtime from the origin server always).
I would recommend you use Next.JS support for server rendering and pre-rending instead of implementing them on your own.

Static HTML with dynamic SEO friendly Reactjs/Nextjs and React Native / React Native Web on firebase?

I apologize in advance for how new I am to this all. I have a new business and there are some things I want to code for it myself as proof of concept till we have enough revenue to actually hire real coders.
Our ecosystem will have 4 major areas and I'm not sure if my approach is how to go about it or even possible.
The normal, static, info webpage that just talks about our business. (SEO and load times important)
A React JS / Next JS non-static section of that same website for blog and other dynamic content. (SEO and load times important)
A react JS employee backend for customer tracking and another tracking of customer data. (SEO and load times not as important here).
A customer portal where they can log in and see stats and stuff about their account (this will pull from data we enter in the employee backend and they can access to track progress) (I would eventually like android/ios apps as well as web portal for this so I was thinking using react-native / react-native web for this section to try and maximize code reuse. (SEO not important, but a smooth experience is)
I planed on using firebase to host it all. I'm curious if this seems it can work? Can you combine all of these different frameworks and strategies in one overall project like this without causing over bloat of download and such? Like for example, the employee backend will likely have a lot of packages and dependencies that the static front end would not require. And the static frontend would be in the same project as the dynamic blog but be built on different things (one static HTML, the other react with next.js? is that a bad idea?). Also, it's been hard to find info on exactly how goog react-native-web is so I'm just lost with this all and would love some guidance. Thank you so much in advance for any direction you can offer.
With firebase hosting you can host static sites, and redirect some paths, such as /api/* or /dynamic/* to firebase cloud functions.
On those cloud functions, you can do dynamic rendering, e.g. with remix.run or next.js.
If you use good cache-headers on those cloud functions, firebase hosting caches the results appropriately, making dynamic rendering of all pages feasible too.

Use flutter web widgets inside a react js app

I have this project where I have to code a website and ios and android apps.
I have to do this with a very limited team (basically myself). So I want to share as much code between those platforms, to avoid maintaining different codebases as much as possible.
I have come to consider flutter : the logic (and interaction with the backend) in dart can be compiled to both ios and android, and to javascript for the web site to call. I also like how the UI is built using flutter.
For the web site, I know there is flutter web that can be used to do a web app, but I want my website to feel like a web site more than a single page app. I have thought about using React+Gatsby to do the website's ui, while calling the dart compiled js for the logic. That would enable high page loading speed, good seo, while keeping the interactivity of a react app and the single codebase logic through dart to js compilation.
I am wondering if this seems like a good approach to you, and if not, how you would do it.
In this approach, I am wondering if it would be possible to embedded flutter web widgets inside of react js components, always in a concern of maintaining as low platform specific code as possible. I have not found any other way of doing this than embedding them into iframes, which does not seem like a good idea, or does it ?
Update
Flutter Web is now available in a stable version for production.
Below answer is relevant back to the time when question was asked.
Flutter Web not recommended
At the current date, I would recommend not to use Flutter Web for production as it's in Beta. The Flutter Team is still working on improving quality, performance and browser compatibility. You must be cautious about using it as you may run into bugs and some other complications.
Also, I believe that the community support for Flutter Web might be on a lower side as it's pretty new.
Limited browser support
Another factor which bugs me is that the Flutter web apps can run on limited browsers as of now which would affect the reach to your user base:
Chrome (mobile & desktop)
Safari (mobile & desktop)
Edge (mobile & desktop)
Firefox (desktop)
What would I prefer?
Well, although it might be a hassle to handle different codebases for mobile and web platforms, I would still prefer to stick with React JS as it's much stable with better browser & community support as opposed to Flutter Web.
Good luck with your app! :)
I am unaware of how to use Flutter widgets inside a React app. But to address your other concerns,
So I want to share as much code between those platforms, to avoid maintaining different codebases as much as possible.
Given no other restrictions, this leads to a single Flutter app for both web and native. For a team as small as three we still found it easier than having multiple projects.
The key factor in merging our initial projects to one was the notion of mobile browsers. In a mobile browser you website should reduce itself to the look of your mobile app, unless they have different purposes. And this automatically happens with Flutter projects if you derive your layout breakpoints from screen size. Otherwise you would code your same narrow design twice: in Flutter for native apps and in React for web.
Same goes for native apps for tablets in landscape mode. They call for a layout that resembles your desktop browser version, and you automatically get it with Flutter.
Also in web version you may have more tools than in a native app, just because your screen allows it. Naturally, you would code this logic in JS. But then you get an order to migrate this to native apps. Would you then replace your JS logic with Dart logic compiled to JS and embedded into frames? This is a messy road.
Lastly, think of Mac, Linux and Windows platforms that will come to Flutter soon. Should you ever need a desktop native app, you would want the same layout as with web.
I want my website to feel like a web site more than a single page app.
The difference in feeling between a website and a single page app lies mostly in state management and URL handling. You may do the following to reduce it:
Introduce URLs for your pages. By default, in Flutter every piece of action can happen under a single URL of example.com/#/. The window then feels fragile as there is no URL to copy and get back to. Flutter's Router API, released in Oct 2020, allows you to generate URLs on any change in your app's state and parse the state back from URL. If you do it right, then everything on your screen becomes a function of the URL, just like in traditional websites.
Use url_stragegy package for your URLs to be example.com/path rather than example.com/#/path which immediately feels fake.
I have not found any other way of doing this than embedding them into iframes, which does not seem like a good idea, or does it ?
No, it does not. Mostly because you get too narrow a channel of communication of messages between JS windows. How would you listen to Flutter's BLoC's stream in another frame? It would take too much boilerplate code. Also I cannot think of easy debugging process.
To me, Flutter Web still has drawbacks:
It takes awhile to load.
Many specific JS APIs are not implemented yet.
Many services you integrate with may not have Dart SDK, while having JS SDK. For instance, I struggled to get Ably working.
No search engine optimization.
You cannot use em as a screen unit, so scaling elements may get tricky.
Still with limited resources a single codebase outweights everything else.
To be clear, my team has been working on a web+native project the whole 2021. It now has passed most of the testing, but not yet released. For a sense of scale, it is a marketplace of 40+ screens.

Deep Linking in React without React-Native or React-Navigation

I have a request from a client to implement deep linking in our React application whereby clicking a link will take them directly into the installed app (potentially to a certain point but not sure on that yet).
To my understanding react-native and react-navigation both handle this as part of a feature set within "Linking" that they offer. However it seems excessive to import a framework just for deep linking (perhaps not though).
After googling I can only really find references to deep linking on react-native or react-navigation.
What is my best course of action?
Let's get to some basics first, then it will be clear.
In modern SPA's, say with React, it's common for the SPA to handle navigation itself. You need to use browser's history API. It's because your SPA is just a single index.html with bunch of js code, so it sort of virtual, every page is constructed by your app. In order to not reinvent a wheel, its easier to use some library for that, say react-router-dom.
But then everything works as expected, and you have deployed your app. When user wants to get some deep page, say, https://my-awesome-app.com/deep/page/1, browser will just send a request to a server, asking: "Please, server, give me a page 1.html, in folder page, in folder deep". But server doesn't have that file, because it has literally one index.html, because its a SPA application. Then we need to tell the server to re-write all deep routes to index html, here is an example for my app hosted on Netlify:
[[redirects]]
from = "/*"
to = "/index.html"
status = 200
When user will ask for that page, server will 'redirect' that request to the index.html and my react-router-dom will figure out which 'PageComponent' to render based on that path.
So, you can implement routing in your app yourself, probably using browser's History API, but I guess it might be easier to use library. But it's your call.
On the other hand if your app is not an SPA, the story might be different, because say in NextJS routing is implemented in framework itself, and if used deep linking would require different setup depending on how app is deployed.
Deep-linking is handled largely by Apple and Google server-side
https://www.adjust.com/blog/dive-into-deeplinking/
React-native provides extended functionality for deep-linking within mobile apps but normal web-applications there is no need to implement it there. Use universal links or Google specific links as standard linking within your web app to enable deep linking

Load firestore data before google bots watch the content?

How can I load the firebase data before Google sees the content?
For example, retrieve data and render it with h1, p and other html tags, but my problem is SEO. I've been watching Gatsby JS but I don't need something like that.
On Firebase, the SEO is called App Analytics and it's possible to disable it on your database. However, you can only disable it generally and not load the data before it starts, once it's activated, it's always working, unfortunately.
I would recommend you to raise a Feature Request for this to be implemented here, so Google can check for further development.
Besides that, in case you want more information about how this is possible, you can check the below documentation.
Disable Analytics data collection
In addition, this question from the Community - How to use Cloud Functions for Firebase to prerender pages for SEO? - there is a case that I believe might help you, since it's about pre-rendering content. This is for another type of use case, but I believe it might help.
Let me know if the information helped you!

Resources