I want to share my components globally. Instead of going with the common isomorphic route I decided to use this guy https://github.com/koajs/react-view.
I can generate user data server side and pass into the koa render method. From there I can import existing components.
I am doing it this way because I have a web app, and a subdomain route that generates a website for my users. I want to share components between the web app and the generated website. So this seems perfect.
However I am using webpack. Webpack allows me to import scss to my component. The react-view lib does not.
My question is how can I compile the imported scss when I am importing the components to the index file rendered by koa?
Related
I want to create a react based theme engine for NextJS, in summary, the user can upload a set of .js files that contains React components, and I want to inject them inside my app on some specific parts.
The question is: It is possible to compile react component and inject them in my app after build and at runtime?
I also open to suggestions, still looking for an alternative of this.
How can we use share components between react-native and react web projects. I have read react native can be derived from react. How is it possible to use same js code between two projects (fully or partially) ?
Take a look at the react-native-web library. It's pretty good:
https://github.com/necolas/react-native-web
As long as you only use react native components, e.g. View instead of div, and Text instead of p etc, you'll be able to share view components between your app and website. Then you can pass down all the data from API calls etc as props from within the individual mobile app/website code.
In my projects I have a common folder that contains all these shared view components, and only put the platform specific code inside mobile or web-app. It works pretty well that way.
I want to move a big Ember v1.4.0 app to React. Instead of creating a new UI from scratch. I want to start building it in React my converting pages over slowly, essentially mixing React and Ember pages in one website.
Goal:
The above is my ultimate goal, but my first goal is is to create a single page in React that is called by Ember's router.
What I have tried so far: I wanted to create a React component in a ./templates/myFirstTestPage.handlebars because, as I understand it, the router.js calls a template file. But I am unsuccessful creating a React component in the handlebars file. Firstly, I cannot use <script> to import React because <script> does not work in handlebars. Secondly, I believe the handlebars is parsing the React app in an incorrect way. Actually, I don't really understand how, and in what order, these frameworks do the rendering.
Possible solutions (but I need implementation details):
Somehow create a React component in the template folder with the .handlebars extension.
Refer to the url of a React app in the handlebars of an Ember app
Have the Ember router map the url to a jsx file. This solution seems really viable to me. I think to myself that surely the creators of Ember must have thought that people might want to have their Ember app refer to some regular html file. Hence, I hope someone might have some knowledge whether this is possible or not.
Somehow create my own router that maps urls to particular files. If its a React component, then I'd map it to my jsx file, if not, I let Ember's router take care of the mapping. I don't really know how to implement a url mapping thing though.
I'm currently working in a multi-language application with Next.js that I intend to host in an S3 bucket.
In this site, I need to maintain an application state across routes, by doing client-side routing from one route to another.
Since I need to support 40+ languages and internationalization, the process to do so is the following:
In next.config.js, use exportPathMap to generate /[language] routes with a variable inside "query" that contains that particular locale for the language.
Load this locale in getInitialProps of _app and pass it down with a Provider, to be consumed in any part of the application using the context API.
To support client-side routing, I've wrapped the next/link component in a custom Link that passes down all props and sets the "as" prop to "/[language]/[route]".
This solution works for now, but ideally, I wouldn't need to "mock" the routing with the "as" prop. I have found that dynamic routing in next does not allow client-side routing in a way to avoid refreshing the page to a new .html file that matches the dynamic path.
E.g:
Using the following directory structure:
/pages
index.tsx
/[lang]/
home.tsx
dashboard.tsx
From index.tsx, clicking on a link from next/link that redirects to /en/dashboard will trigger a request to the server and refresh the page completely. Thus, losing the client state.
Is there a better solution for this? It seems like a very common problem to solve, yet I cannot find an elegant solution using Next.js.
I just wanted to know the difference between react router and react habitat. From what I have been reading (which is not much) these two solve the same problem of externalizing components of a website. I would like to know why one would consider one above the other if they are even comparable in this manner.
React Habitat does not worry about routes or the application information architecture (IA). It simply lets some other system render HTML pages how ever it likes and will hook up one/or many React apps on the fly when ever it see's targets in the html. If a CMS content author changes the URL of a page, or adds a new page no problem React Habitat doesn't care and will continue to hook up React apps.
React Router use routes (urls) to mount React components, this means it needs to know allot about the IA of the application and cant simply be 'dumb' to it like React Habitat. If a CMS content author changes a URL React Router will no longer render, it will require a developer to update the route in the javascript. You could be fancy and dynamically load routes from the CMS but I would question is this too tightly coupled.
They both solve different problems.
1) If you are building a SPA or PWA and want to hold all the IA in the javascript application then use React Router.
2) If a system (.net/php/java/etc) is rendering your HTML such as a CMS and it holds all the IA then use React Habitat.