Is their anything in web components (lit-html) like error boundary in React.
Looking for something equivalent, I've stumbled upon Salesforce's LWC errorCallback(): https://developer.salesforce.com/docs/component-library/documentation/lwc/lwc.create_lifecycle_hooks_error
Looking briefly at the implementation, it requires cooperation from the throwing component and the error boundary: the component will have its own methods catching exceptions, then walking up the DOM tree until it finds an error boundary (which it identifies as a LWC component –this itself is done through a field with a known Symbol– with a defined errorCallback() method); so it will only works between two LWC components.
To make it work across component frameworks, I suppose one could dispatch an ErrorEvent from a component (this still requires components to handle their errors to dispatch that event) and have it bubble the DOM tree up to the error boundary component which would handle it (and stopPropagation()).
Related
I have a store pattern that contains reactive objects outside of the components that use them (I call it a store because of this page https://v3.vuejs.org/guide/state-management.html#simple-state-management-from-scratch)
So, a reactive object is shared across an unknown number of components that may or may not be currently rendering content on the page.
But I have some synchronization logic that is expensive, so I only want it to run for objects in my store that are being used.
In Vue2, I found an undocumented way to do this.
reactiveObject.__ob__.dep.subs.length
The Subcribers are visible, and if a component is no longer rendered (is not the current route in vue-router for example) then Vue2 did a perfect job of unsubcribing when removing that component from the DOM.
I'm upgrading to Vue3, and as far as I can tell, it called "Tracked" instead of "Subscribed" but this tracking information seems to be in a private scope (might be the targetMap variable that Vue3's source code uses during track() and trigger()).
Is there a way to know if a Vue3 reactive object is currently being watched? To know if a change to that object will trigger anything?
Creating an application that uses redux state quite seriously.
While passing values between the UI components and the reducers. The immutability has become a problem.
1) The cycle problem - I have forms that create JSON objects - which are then used by reducers to maintain the model. The next time you use a form, it is set to the earlier state,.. and either gives error or updates the previous attribute along with itself. Is there someway to capture things in non redux state and then pass it to the states for process?
2) Redux returns or reducers become extremely unmanageable on scale. I have started using immer for this. Is this a good choice?
Are you using Reactjs for creating the forms?
To benefit most from immutabilitiy it is best if your design embraces it also.
What I mean: Develop a form which just displays your data. (a pure form, or FormPure)
Then wrap this form / component by another component which holds the state of the form to be displayed and actually displays the data through the pure form. And allows you to just edit it.
The hierarchy would look like: App > Form > FormPure
Components
Form:
Connected to Redux
May have its own state.
FormPure:
Does not know about redux
Only displays data provided from its parent (in react via props and communicated via callbacks up)
When the user hits the Save Button then the connected Component (Form) may dispatch an action to update the state in redux.
This way you may build your FormPure in isolation separately from any data, and just bring it to live as needed.
You may consider using Storybook for nicely designing your components.
For 2: Yes immer is reasonably fine to use, just make sure you are not overusing it by creating to large object trees, as described in the documentation.
Also make sure to turn off autofreezing when deploying it to production.
Hint: immer uses Proxy make sure your target platform supports them, or make sure to switch then to the ES5 implementation which is considerably slower (see, immer docs)
I'm using Prism Forms 7.x in a Xamarin Forms app. Up to now, I was using the INavigatedAware interface in view models to check if a navigation to or from the respective view model happened. Now, I saw that there is INavigatingAware, which only provides the OnNavigatingTo method (so, the navigation is not yet finished).
My questions regarding INavigatingAware.OnNavigatingTo:
- Can I use INavigatingAware where I'm not interested in the OnNavigatedFrom call?
- Is it better in terms of performance to load data within OnNavigatingTo (before the BindingContext is set; so that e.g. the data binding don't need to be updated twice)?
Would be nice to share your experiences and best practices regarding those two interfaces.
INavigatingAware.OnNavigatingTo was first introduced to Prism to assist developers perform initialization logic similar to the ViewWillAppear.
To help better visualize this the events look something like this within the NavigationService:
Create the Page
Set the ViewModelLocator.Autowire property if it is null
Apply any behaviors from the PageBehaviorFactory
Call IConfirmNavigation.CanNavigate (and it's async counterpart) on the Page/ViewModel we're navigating away from
Call INavigatingAware.OnNavigatingTo
Push the page onto the NavigationStack
Call INavigatedAware.OnNavigated{From|To}
BREAKING CHANGE
Now, all of that said, we have had a tremendous amount of feedback on INavigatingAware (the essence of this very question), as a result over the overwhelming feedback from the Prism community INavigatingAware has been a hard obsolete in Prism 7.2. This means that it was removed from INavigationAware, and will throw a compile time error if you directly implement it. For those times where you got it for free from INavigationAware, it simply will not be called. Moving forward, we have introduced a series of interfaces to make this easier and more self documenting as to the intent.
New Interfaces & API
IInitialize.Initialize
IInitializeAsync.InitializeAsync
The new IInitialize interface is the direct replacement for INavigatingAware. We have long gotten feedback that people would like the ability to perform async tasks during initialization. The issue here is that this can cause a very noticeable delay in Navigation similar to IConfirmNavigationAsync. If you use either of those async interfaces, you will need to be sure to include some sort of busy/loading overlay on your screen.
I love Redux, but to use it, I have LOTS of additional code scattered all over my application: connect, mapDispatchToProps, mapStateToProps etc etc
It appears to me however that I should be able to both dispatch to the store and get any value from the store via a global window level reference to the store object. If I did this, it would cut alot of code out of my application.
So the question is, what is wrong with this approach? Why NOT do all my Redux disptach and state access via window.store?
I wrote a long Reddit comment a while back about why you should use the React-Redux library instead of writing store code by hand.
Quoting the main part of that answer:
First, while you can manually write the code to subscribe to the Redux store in your React components, there's absolutely no reason to write that code yourself. The wrapper components generated by React-Redux's connect function already have that store subscription logic taken care of for you.
Second, connect does a lot of work to ensure that your actual components only re-render when they actually need to. That includes lots of memoization work, and comparisons against the props from the parent component and the values returned by your mapStateToProps function for that component. By not using connect, you're giving up all those performance improvements, and your components will be unnecessarily re-rendering all the time.
Third, by only connecting your top-level component, you are also causing the rest of your app to re-render unnecessarily. The best performance pattern is to connect lots of components in your app, with each connected component only extracting the pieces of data it actually needs via mapStateToProps. That way, if any other data changes, that component won't re-render.
Fourth, you're manually importing the store into your components, and directly coupling them together, thus making it harder to test the components. I personally try to keep my components "unaware" of Redux. They never reference props.dispatch, but rather call pre-bound action creators like this.props.someFunction(). The component doesn't "know" that it's a Redux action creator - that function could be a callback from a parent component, a bound-up Redux action creator, or a mock function in a test, thus making the component more reusable and testable.
And finally, the vast majority of apps built using React and Redux use the React-Redux library. It's the official way to bind the two together, and doing anything else will just confuse other developers looking at your project.
Also, per the Redux FAQ entry on importing the store directly:
While you can reference your store instance by importing it directly, this is not a recommended pattern in Redux. If you create a store instance and export it from a module, it will become a singleton. This means it will be harder to isolate a Redux app as a component of a larger app, if this is ever necessary, or to enable server rendering, because on the server you want to create separate store instances for every request.
Summarizing all that:
Better performance
Lower coupling via dependency injection of the store
Better testability
Better architecture
I'd also suggest you read through my two-part post The Tao of Redux, Part 1 - Implementation and Intent, and The Tao of Redux, Part 2 - Practice and Philosophy. These two posts discuss the history and intent behind Redux's design, how it's meant to be used, why common usage patterns exist, and other ways that people may use Redux.
I am not an expert in flash, but I do work with AS and tweak Flash projects, though not having deep expertise in it. Currently I need to revamp a flash website done by one another guy, and the code base given to me, upon execution is throwing the following error:
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at NewSite_fla::MainTimeline/__setProp_ContactOutP1_ContactOut_Contents_0()
at NewSite_fla::MainTimeline/frame1()
The structure of the project is like, it has the different sections split into different movie clips. There is no single main timeline, but click actions on different areas of seperate movie clips will take them between one another. All the AS logic of event handling are written inline in FLA , no seperate Document class exists.
Preloader Movie clip is the first one getting loaded. As i understood the error is getting thrown initially itself, and it is not happening due to any Action script logic written inline, because it is throwing error even before hitting the first inline AS code.
I am not able to figure out what exactly is causing the problem, or where to resolve it. I setup the stuff online, for reference if anybody want to take a look at it, and here is the link. You need to have flash debugger turned ON in your browser, if need to see the exception getting triggered.
I really got stuck at this point. Any help will be great. I had not seen the particular solution I am looking for anywhere yet, though Error #1009 is common.
Did you set the option "Export at frame 1" for the classes in your library?
I get this error for instance:
I have a circle which is a Circle class and put it on Frame 10.
If I try to attach a eventHandler to it from frame 1, I get this error.
Set the option "Export at frame 1" for my Circle class will solve this issue for me.