I recently started playing around with preact and am intrigued by the ease of use and the performance. I have also been eyeing react's new context api (preact has a library preact-context to operate the same way).
Are there any examples or applications someone can share/reference using preact that leverage combining socket.io and preact-context?
I am specifically looking to compare the "preact+preact-context" way as opposed to the "react+redux+router+thunk+saga+..." way especially as it relates to a SPA desktop-style application
The SPA application I am looking to build will be an MDI (multiple document interface) so not a content serving app where the state can all be held in redux. We are finding also that doing things the "Redux" way is adding a lot of overhead and complexity to our code, so I am trying to see if there is a better method.
What I am hoping to understand from some provided examples:
What would a SPA-type application look like without redux using context api? (I guess this is the same for react & preact)
What are the pros and cons of doing a SPA using context api?
Can socket.io be used in a context api provider in some way?
Related
The company I am working for has a strong .NET and Microsoft SQL Server backend that I can not change. But we are front-end agnostic. Lately we have been in need of upgrading one of our older apps and I have been looking for solutions. I am looking to use React and Redux as I think they would be the closest to a single code base application between web and native applications. But I need to figure out how I can make sure React can work with .NET and MSS.
So far I have thought about starting with building an ASP.NET Core 2 GraphQL API backend which I know will work with MSS. But I am not sure how that would work with Redux. Here is the article I would start from:
https://fullstackmark.com/post/17/building-a-graphql-api-with-aspnet-core-2-and-entity-framework-core
I have also looked into using Apollo Server, but I am not sure if I would have to add another .Net layer in between Apollo and MSS.
I am just wondering if anyone has any experience in this stack so I can prevent myself from re-inventing the wheel. Any thoughts, suggestions, articles would be helpful and appreciative.
I am currently working on a project that uses React with TypeScript & GraphQL (among other things) and a C# .NET Backend. We use https://github.com/graphql-dotnet/graphql-dotnet on the server side which works pretty well.
We aren't using Redux, but I don't see why that should be an impediment. Any issues with compatability between GraphQL and Redux shouldn't have anything to do with the server implementation.
There are plenty of Articles on the internet that talk about using both.
https://www.robinwieruch.de/react-redux-apollo-client-state-management-tutorial
https://medium.com/react-weekly/implementing-graphql-in-your-redux-app-dad7acf39e1b
https://www.freecodecamp.org/news/tutorial-how-to-use-graphql-in-your-redux-app-9bf8ebbeb362/
I think the question is a bit unclear:
If you claim that your API is front-end agnostic then why shouldn't it work with React/Redux Or any other front end technologies?
As For GraphQL, In my opinion React Is a decent choice to consume GraphQL APIs as they are both managed by the same company.
For .Net GraphQL Framework I'd Recommend Hot Chocolate. It's an fast growing open source graphQL server framework for .NET technologies.
Also As Front-end GraphQL Frameworks Relay might also be a good choice as it's more powerful than other graphql clients but tends to be more complex.
But the main question you should ask yourself is if you really need to use GraphQL at all. If your API is not too generalized and you know exactly when and how each data endpoint is going to be used, then why not go with REST? As you might know GraphQL has it's limitations and is not an universal solution.
Here Are some articles which explain when to use GraphQL over rest and when to do otherwise:
Rubrik.com: GraphQL vs REST
stablekernel.com: Advantages and disadvantages of GraphQL
dzone.com: when and why to use GraphQL
My question is, can I use the react framework with #spartacus storefront? this is because our frontend application is developed in React and we want to use #Spartacus storefront to leverage advantages like decoupling front-end and Hybris build ..etc. but as it is developed on angular I am not sure whether it supports other frameworks like React within it.
There is some effort in making possible using web components as cms components, so you could use any technology to author them (including React), but it's still in the experimental phase (but works already).
More info is available in the docs:
https://sap.github.io/cloud-commerce-spartacus-storefront-docs/customizing-cms-components/#using-web-components-as-cms-components-experimental-support
And here you can find some example POCs for React, Vue, and Svelte:
https://github.com/dunqan/react-cms-web-component
https://github.com/dunqan/vue-cms-web-component
https://github.com/dunqan/svelte-cms-web-component
Spartacus needs Angular. So, I would say "NO", unless you want the complexity of integrating Angular with React.
Regarding of what backend you use to power the API behind a React app (Ruby on Rails, Node.js/Express, Java, etc), what are the consequences of making the frontend React app separate repository?
I like the idea of having my ReactJS app separated from my backend API code, just want to understand the pros/cons of going with this approach.
pros
front-end devs doesnt have to get familiar with backend
You can choose not to show your secret recipe.
can upgrade and deploy one without the other
Code Reusablity
Lazy loading for better UX
I actually dont have any cons to tell about this. it's just that i feel right developing apps like this. installing npm packages in RoR felt so wrong.
more Pros -
You new separate UI can link to more backends than 1 - think centralized UI for disparate components
Like Angular more, bang you got it
Like React more than Angular, bang you got it
Cons -
Needs added work to setup CORs
You will probably have to cookup secret sauce for pagination, serialization (i.e tied together even though separate) - not a problem if you follow a standard anyway
Need to have a long deep thought on behaviour when the backkend is down
Need to wrap brain around pull vs push
You now have 2 diff OS stacks & TCP stacks in the picture to increase your work on sys admin patching & understanding latency between the components
wrap brain around state & its management
IMHO separating the UI is worth all the cons given the pros outlined here & by Shan
Learning a little React currently. I'm finding myself confused about some of the utility here. One sticking point that seems to (for me, at least) undermine it's value is that If I want to sync my UI to data residing on the server (which can and will change), I need to manually poll the server? Aside from component-based architecture, I'm not sure how this is getting me further than well structured and logically implemented AJAX. Even in the React docs, they're using JQuery in this regard. https://facebook.github.io/react/docs/tutorial.html#updating-state
I'm sure I'm missing the forest for the trees or whatever.
Thanks!
React is (citing their page)
a javascript library for building user interfaces
The main focus is to build a view layer for your application. This means you have full freedom in choosing what to use to fetch your data. For simple uses it can be jQuery or fetch.
It's generally recommended to not fetch data directly in your components and use one of Flux pattern implementations, e.g. Redux.
If your application has to be constantly powered by new data from server you can think about using something like RethinkDB on your backend and connect it to Flux store on your frontend.
I know what angular.js is and I even had a question about it #Why use AngularJs in frontend if Laravel is already used as backend?.
but recently I started to read about React.js and from its site (its the V in the MVC) which is exactly what am after "handling the view and nothing else".
for me, I think Angular.js as an MVC framework was made to be used with something that is built with JavaScript from start to end like Node.js
and it seems like an overkill when used with something like Larval, where I simply need something to handle the frontend and nothing else + Angular have 2 main drawbacks
with the latest news about a new version that won't have back compatibility with the current version makes me even feared to start learning it just to find that more or less every project out there is using the old version which mostly is true.
angular renders the whole dom if anything got changed which again is an issue for big projects.
so based on the above, plz note that I want to learn/use JS solely to enhance the user experience not to build another Gmail or Facebook and so my question is,
could React.js be used with Laravel to handle the view and do everything Angular was going to give, or I have to use Angular liked or not?
could React.js be used with Laravel to handle the view and do everything Angular was going to give?
No
React is just for views. React components are stateful components with some really clever rendering stuff happening behind the scenes. To build a fully functional front-end app, you'd need to tie in some other code (or write it yourself).
React works well with Facebook's Flux architecture. I would suggest looking into that to learn how to manage the state of your react components.
What's key to understand here is that Flux and React are not parts of a large front-end framework. React is a library and Flux (as provided by Facebook) only provides a Dispatcher. The rest is up to you to implement. There are some pre-existing implementations you can look at if you need some help to get started.
What I like about flux is that it allows me implement things the way that fits my application best. React takes care of the heavy DOM lifting and is very easy to learn. Compared to Angular, I don't have to learn arbitrary conventions and gigantic APIs of a huge framework.