I'm working on a new project where I'm taking a full-stack application and decoupling the UI from the backend -- so basically our backend will be just a JSON API a new React-based frontend talks to.
The way our current full-stack architecture works is we have a base application in /core/app and then a client overrides folder for each client /clients/client{1,2,3}/app and then our file include logic checks the client folder first and then the core folder as a fallback.
Like php include_path precedence logic.
I feel pretty confident in how I'll setup the core app, but I'm not quite sure how I'll handle this override concept.
Ideally when I call:
import MyComponent from '../components/MyComponent
I know import statements can't be dynamic, but I'm looking for a solution to check in /clients/client1/components/MyComponent first and then /core/component/components/MyComponent second.
What is the recommended way to handle this sort of usecase? I thought about trying to be fancy with symlinks (ie: by default, each client gets a symlink to every single item in the core and then they'd override it as needed and replace the symlink).
That seems kind of hacky and I'm not sure how it'd work with hot-reloading so I'm hoping there's a more elegant approach.
Related
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
For normal functions, I think it is okay to incorporate all pages in to one react app using routes.
But when it comes to admin page, I think it is wise to create a separate react app which will compile into a different .js bundle and serve this not though react route but a totally different html along with the separately created js bundle.
I think if we bundle admin and normal functions into one file and serve through react router, there is a risk where the client can look into the js file and decipher admin pages. Couldn't this be a security risk?
If I'm overthinking please let me know. Other feedbacks are also welcome
Assuming that whatever backend is serving your React application has properly-implemented authentication, it's not technically a security flaw; a malicious actor can't negatively affect your product purely based on the admin page source being bundled with everything else.
That said, it does make it easier to see how your admin tools work, and gives someone nefarious a good indication of where they need to look for exploits.
Personally I'd never serve up a consumer-facing application and admin-facing application in the same codebase. Even though it's not exploitable directly, it makes it easier to find a potential exploit. Security through obscurity is largely a fallacy, but it never hurts.
You can use lazy loading, not to send whole pages in one bundle. but if they are totally different with no functional overlap, it's better to separate them, better responsibility separation, cleaner git history, etc ... And unless you are not exposing valuable data like hard coding api key, reading js source isn't a problem. The security breach happens in the back- servers and the back end services should be using some sort of authentication to respond, check OAuth, OpenID workflow. Its a very common pattern and used by tech giants.
I am using React in my project and I have problem with client-side prerendering.
More specifically, it would be necessary to configure SEO
Which is the least painless way to prerender existing reactjs app wiht react-routes
Some examples I have researched:
Gatsby.js - https://www.gatsbyjs.org/docs/porting-from-create-react-app-to-gatsby/
Next.js - https://nextjs.org/docs#custom-document
Netlify - https://dev.to/joelvarty/prerender-your-spa-using-netlify-for-better-seo-3h87
React-snap - https://web.dev/prerender-with-react-snap/
Prerender.io - https://prerender.io/
Keen’s Server Side Rendered - https://medium.com/keen-studio/keens-server-side-rendered-react-wordpress-rest-api-boilerplate-bb58edb7cc0a
Razzle - https://reactresources.com/topics/razzle
React Helmet - https://github.com/nfl/react-helmet
Can anyone suggest what option I should choose that is the least painless.
I have headless wordpress as backend and reactjs client-side as frontend.
Or are there other faster options besides the prerendering?
Thanks.
IMO you really don't need to use a framework to achieve SSR if you want to keep control without turning your codebase into a blackbox and choose your own stack.
I created some boilerplate using Node Express. It supports:
SSR using StaticRouter on the server and BrowserRouter in the client
ES6 webpack transpilation + hot reloading both client and server and auto-updating browser
Redux, data preloading and client store hydration
https://github.com/kimgysen/isomorphic-react-setup
Last time I ran it, I noticed that I hadn't saved the favIcon in the public folder and perhaps there are some minor bugs that I will fix soon (I've fixed them in my projects but didn't update this repo because nobody looks at it anyway (lol!)), but what happens here isn't all that difficult to understand.
I created some basic SSR websites with it in a matter of hours.
I enjoy redux-observable to initiate server ajax calls before rendering the content (using forkJoin), but this is not included in the boilerplate (I haven't actually supported it since I uploaded the first time).
But in terms of setup, I don't really see a point in using a framework for this necessarily, it really isn't that painful / difficult to do yourself.
The benefit that I particularly like is that you don't depend yourself on the scope and dependencies of the framework. You don't get into trouble with things like 'the framework will support this feature or fix that bug in one of the upcoming releases'.
Although ultimately, it comes down to personal choice. So it's not like I want to downgrade these frameworks.
Note: The way Redux achieves pre-rendering is simply by adding Redux store (state) objects to the window object in the html that is sent back to the client.
Then at the client, the it initializes the stores with these objects.
So very simply, this is something that is easy to achieve, even if you decide not to implement any other SSR features.
to create server side applicantion with painless integration you can use my cli to generate a default configuration like create react app cli from facebook, https://github.com/ghondar/crassa
I have recently worked in a pure Scala-Play application and later in a pure AngularJS application. I'm very impressed with both and I'm wondering what is the sweet spot of combining the two frameworks together. Since the two frameworks can be complementary but also overlapping in different areas e.g. MVC and page routing, as far as I know these are some of the possibilities:
Single Page design, use AngularJS MVC-only and use Scala-Play as "dull" service layer backend with no full page refreshes.
Allow page reloads and each page reload becomes a different AngularJS root application. This seems quite flexible e.g. the client side is not bloatted with so much data for larger applications but better partitioned for the different use-cases. The downside is that I'd need different AngularJS MVC applications and I'm not even sure how to organize it as a project. Are there examples of this?
Typical server side Web App, use Play MVC-only and AngularJS for handling UI models for each separate page.
My choice of IDE for these types of architecture would of course be WebStorm but unfortunately I can't have all client-side (AngularJS and JavaScripts) and sever-side (Scala-Play) codes in a single project.
I believe that there is no the ultimate optimal architecture for combining Play and Angular. It depends on the specificity of the project, team etc.
The decision to develop UI part with Angular and the server side back-end with Play is very reasonable. Technically it may be done as following:
Development:
Both parts are developed as detached projects with the preferable IDE.
The client should have some entry point HTML page. It is reasonable to name it index.html, but is may be any other name.
For client-server integration do on the Play side as following:
Select a sub-folder under the play application root, which will serve as the "home" for the client files. The default solution is to use the folder public, since all files under it are automatically deployed.
All client files should be copied under the public folder. The files may be organized in any structure.
Add a route for the default URL as a route to the index.html. The argument path in the route should be the full path of the index.html relatively to the application root.
If index.html is directly in the public folder, the route is like this:
GET /defaultUrl controllers.Assets.at(path="/public", file ="index.html")
Add routing to the client files:
GET /*file controllers.Assets.at(path="/public", file)
Now the distribution package will include all the client files.
Putting of the client files into the public folder should be done automatically, for example by organizing the client directory structure and appropriate configuration of the client IDE.
You can find more examples in this post.
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.