I'm currently using Remix + Redux and need some direction on how to provide initial state to Redux so that it's coordinated with the state on the pre-rendered page.
I am aware that Remix wants you to potentially forget traditional state management, but for many company settings that's a non-starter. My app also needs a lot of coordination.
I understand that you can fetch data from an endpoint after the app has already loaded, but I'm asking for SSR-time.
Related
I'm very new to React Native (did some courses) and now building my first app on my own which is going great, but I need some advice regarding user applied filters and how to handle this.
Quick summary of what needs to be done.
The user should be able to set some filters so only certain data is displayed and this state is saved even after closing the application, user logs in again and still sees only the data that is filtered because of the filter option he/she set before.
In one of my courses I got an introduction into Redux and my question here is should I use Redux for this feature or maybe Context for this ? My data is fetched from Firestore and I'm able to use a query to filter data from firestore but that just ends up in many read/writes which cost money.
All advice is more than welcome!
use redux
when you need some static state globally in your app then use context like open close drawer etc. For dynamic states go for redux
As mentioned in stackoverflow answer :
As Context is no longer an experimental feature and you can use
Context in your application directly and it is going to be great for
passing down data to deeply nested components which is what it was
designed for.
As Mark Erikson has written in his blog:
If you're only using Redux to avoid passing down props, context could
replace Redux - but then you probably didn't need Redux in the first
place.
Context also doesn't give you anything like the Redux DevTools, the
ability to trace your state updates, middleware to add centralized
application logic, and other powerful capabilities that Redux enables.
Redux is much more powerful and provides a large number of features
that the Context API doesn't provide, also as #danAbramov mentioned
React Redux uses context internally but it doesn’t expose this fact in
the public API. So you should feel much safer using context via React
Redux than directly because if it changes, the burden of updating the
code will be on React Redux and not you.
It's up to Redux to actually update its implementation to adhere with
the latest Context API.
The latest Context API can be used for Applications where you would
simply be using Redux to pass data between components, however
applications which use centralized data and handle API requests in
Action creators using redux-thunk or redux-saga still would need
Redux. Apart from this Redux has other libraries associated with it
like redux-persist which allows you to save/store data in localStorage
and rehydrate on refresh which is what the Context API still doesn't
support.
You can refer to the blog1 and blog2 in order to get more clarity on when to use redux and context.
React (Typescript & Redux & Webpack)
I'm developing a micro front-end application using react (typescript & redux & webpack)
But I'm seeing blockers in sharing the data between container app & child apps,
Above the planned structure, there roles based authorization
Teacher (Access to Teacher - Student Management App & Student - Academic Assessment && Teacher Registration App
Parents (Acccess to Parent Registration App && Student - Academic - Assessment
Student (Student Registration App && Student-Academic Assessment App)
Now, I'm seeing a blocker in sharing the redux-store data across child applications, i.e. when users log in from the login app, how to share the logged user information to child apps so that role-based access is implemented effectively, data is also to be shared. Store should not be shared across apps.
Honestly, you are making things more complicated for yourself that it needs to be. To make some of that data available to each other, you will end up with multiple copies of the same data in different stores that has to be kept in sync.
Just share that store instead of coming up with a complicated scheme of making some application state available to some others and not others.
If you suddenly start accessing another sub-app's data, chances are you actually need that access. And then you will have to enable data sharing there again - which you could have from the beginning.
Another solution for this would be to add some code rules. A "human" solution, not a "technical" if you want to phrase it like that:
one central store
an app can only dispatch actions from it's own app
one app's reducers can listen for actions from other apps (this is how app A could lead to a state change in app B if you need it)
you only use selectors, no inline-written selectors
keep all selectors in a central (but scoped) location for all apps to access, but add a linter rule to "forbid" import of certain scoped selectors to other apps. You can easily disable those rules for certain combinations to allow read-only cross-app access.
I am currently developing an app with Vue.js and Firebase database.
I am listening to real-time changes of one of the database documents, at the App.vue level.
In a child component, I would typically unsubscribe from the database in the beforeDestroy() Vue.js lifecycle.
Is there any point of unscubscribing at the App.vue level?
Thanks!
If you believe that all subscribes should have matching unsubscribes, for the purpose of code symmetry, and communicating to other readers of your code when the subscription is expected to end, you might choose to add that code.
If your code runs in an environment (perhaps a test environment) that does not fully get destroyed when the lifecycle is complete, then you'd probably want to make sure your app releases its resources correctly.
Or maybe you are just concerned if there is any chance at all a subscription might leak, causing you money over time as it causes reads when those reads will not be used, so you choose to clean up properly just in case.
We are building a to-go order web application for restaurants with Firebase and Vue.
Restaurants can create their own pages, and add menu items.
Users (customers) can orders some foods from those restaurants pages, and pick them up later.
At the beginning of the project, we have chosen to store some transient data (user data, shopping carts, etc.) in the Vuex store. It works fine but there are a lot of complexities in it, which made it hard to maintain.
Recently, I have realized that we could just use Firestore for those transient data as well, which will greatly simplify the architecture, eliminating Vuex completely.
Before making all the changes, I want to make it sure that I am on the right track and I am not missing anything.
I'd really appreciate any comments and suggestions from those people who have experience in building relatively large scale web applications using Firebase + Vue (or even React).
Short Answer
Yes, this seems perfectly reasonable.
Long Answer
Many web applications have their state synchronized via an external service like Firebase, GraphQL, etc. In these cases you may already be using some kind of shared, UI-independent cache (e.g. Frestore, Apollo client). Unless the aforementioned cache cannot be easily accessed by your UI components, there would be little benefit to switching or duplicating the data to Vuex.
Keep in mind that even in the above scenario, Vuex can still be a useful tool to track UI-specific state across otherwise disconnected components in your interface. For example, you could globally identify the user's current viewing mode, or which modal is open.
Yes you can go without VUEX, however, it will limit your potential.
First of all vuex is really simple, you can easly add vuex your code.
Without Vuex you may write same code again and again.
For example you want to redirect your user to his restaurant page when he logs in. So you write a code that first checks if user has a restaurant and then gets his restaurant ids.
Also you want to check when a user opens a restaurant page, if the user owns that page, you write the same code again. However, if you have a function that returns a value if user is the owner or not. You can call it any page you want.
I'm looking to persist the application NgRx store to either local storage or a NoSQL database. This is so the application/user can resume from where they left the application last time they visited.
However, if the structure of the state has changed in my application the old persisted state will need to be migrated to the current one. Is there a way to do this with standard NgRx tooling or features or another popular pattern/method?
There is no generic way as far as I know, it's up to you to handle structure changes - we can't make those decisions for you.
The answer also depends on what you store, is it the full state or are you storing the actions. Both are valid and serve different needs.
If you're storing the full state, you'll have to provide a migration to migration from version 1 to version 2.
If you're storing actions, you'll have to keep the reducer functions to handle those actions.