Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I created new react native project as per client requirement.I have knowledge and yet not any project done so please give me any project structure how to build
this project.
Or give me any git hub link
Thanks
In your scenario, you can make your own folder structure or I have some example which I follow by myself.
type vs feature
Separating by type means that we organise files by their type. If it is a component, there are container and presentational files. If it is Redux, there are action, reducer, and store files. If it is view, there are JavaScript, HTML, and CSS files.
src
app
api
assets
redux
actions
reducers
store
components
containers
navigation
styles
utilities
src/
All the files are inside this base component.
api/
This folder contains logic related to external API communications, it includes:
constants.js - where all required static values are stored.
helper.js - for storing reusable logic.
individual feature files — Each feature file contains api communication logic for a particular feature.
assets/
Just as the name implies, this houses static files (e.g images) used in the application.
redux/
This holds all the redux files if you are using react-redux for managing state. Inside redux folder you have actions, reducers, store which can easily manage your redux files
redux/actions
All the action files which are using around redux goes here.
redux/reducers
All the reducers which are using around redux goes here.
redux/store
You can put your store inside this redux store folder.
components/
Shared components used across features are placed in this directory. An example of such (as shown above) is the layout component, which is used to wrap the application components and determine its overall layout.
containers/
You can put you all screen-based components inside here (Eg - SplashScreen, HomeScreen).
navigation/
You project base navigation goes here. You can create stack navigator and export it to your application.
styles/
If you have global styles defined in your project you can put it over here like colors, font styles like things.
utilites/
You can put utils files over here.
Note: This structure is based on my experience. You can create your own structure once you done with more experience
Refere these links also
https://medium.com/the-andela-way/how-to-structure-a-react-native-app-for-scale-a29194cd33fc
https://www.freecodecamp.org/news/how-to-structure-your-project-and-manage-static-resources-in-react-native-6f4cfc947d92/
https://github.com/asimolmez/react-native-folder-structure
https://github.com/thecodingmachine/react-native-boilerplate
Related
what is considered the best practice for string constants constants used throughout the entire application such as constants used in home screen and others, would it be considered good practice to combine them all in one file or to have multiple files- ( constants file for home screen and so on)
There is no perfect answer to your question but just follow what makes sense to you and your project. You can also follow best practices. For example, an MVC-layered project will not have the same structure as a pure backend microservice. Still, these can have similar best practices.
To answer your question, a React Native project normally does not have a ton of constants, I don't see a real value in creating multiple files for constants. I would just have a constants.js file under /src.
src/
- constants.js
If you still think multiple files are necessary, maybe having a /constants folder under /src will keep it organized. You can also have an index.js file.
src/
- constants/
- home.js
- menu.js
Furthermore, The Twelve-Factor App suggests having constants in environment variables. Obviously, this is not very practical for variables used with UI purposes, but rather variables that are part of the configuration of your project, such as database connections, URLs, etc.
Again, the short answer is to do what you think it's best for your project (scalability and deployments) and always trying to follow common best practices.
I was trying to test Lazy-loaded CMS components on ongoing Spartacus project with version 2.1.4 and I wasn't able to properly display the components. Before I continue with further investigation, I just want to check couple of things:
is it possible to lazy-load components which we have overriden, for example BannerComponent, SearchBoxComponent...?
is it possible to apply lazy-load on custom CMS components ?
are there any limitations when this feature won't work? Maybe in combination with some other feature?
There are many OOTB Spartacus CMS components that we have overriden in our project, and I have defined lazy-load feature for couple of them like it is described here https://sap.github.io/spartacus-docs/customizing-cms-components/#lazy-loaded-cms-components-code-splitting inside modules for certain components, this is one example:
breadcrumb.module.ts example here
and after the build, chunks are there, visible from source tab also, but components aren't displayed and there are errors because of missing modules (such as CommonModule, RouterModule, basically for everything that we used in our custom implementation..) which are declared in corresponding module but for some reason aren't registered at all.
Any guesses what we should fix in order to check if this feature is working in our architecture?
I suggest to stick "CMS-driven lazy loading of feature modules" (as explained here: https://sap.github.io/spartacus-docs/lazy-loading-guide/) instead of lazy loading of separate components (using component: () => import()) as it's simpler to make it work.
The idea is to define CMS mapping inside the module, which then will be lazy loaded (with components, services, etc.) instead of lazy loading separate (and decoupled) components. Then, in the root application, we let Spartacus know, which feature module should be loaded, when we want to render specified component (example: https://sap.github.io/spartacus-docs/lazy-loading-guide/#configuration-of-lazy-loaded-modules)
Using component: () => import() will lazy load only component code (no module, unless defined in the same file), such a component will have access to global (root) services, etc. It's still useful in some cases, but a bit problematic to make it work in more than basic scenarios (but this will improve in Spartacus 3.x/4.0).
Regarding your questions:
is it possible to lazy-load components which we have overriden, for example BannerComponent, SearchBoxComponent...?
Yes. Briefly explained here: https://sap.github.io/spartacus-docs/lazy-loading-guide/#wrapping-library-code-in-a-lazy-loaded-module
is it possible to apply lazy-load on custom CMS components ?
Yes.
are there any limitations when this feature won't work? Maybe in combination with some other feature?
As explained above.
I want to know what is the best way to order the folders and other components in a vue.js project so that it can be easily maintained and scalable
Like the comments already say there are a lot of ways and opinions of how to structure your vue project.
Like tony19 already said it's a good start to use the vue-cli to generate a project.
If you want to see a real world example of a project you could try this one: https://github.com/gothinkster/vue-realworld-example-app
gothinkster actually has an example of the same project in a lot of different frontends and backends. just look at their repos.
If you plan to use vuetify as your ui library i can also recommand to have a look at their free templates
https://vuetifyjs.com/en/themes/premium/
There are plenty others of course. You might want to search for "vue real world example" or something similar on google.
For scaleability i would say to split things into smaller files and components is a good practice.
For example when creating a vuex module you could have a file for the complete vuex storage or a file for each module or even split each modules into an actions.js, mutations.js getters.js state.js and an index.js which combines those 4.
Please keep in mind that all of the above is my opinion and others might think differently.
I'd advice you to go for the standard cli-structure - but remember that you can still add sub-folders everywhere and don't get caught putting in 200 files under modules or something like that.
If you're about to make a module - add a folder.
If you're about to add a component - add a folder
and so on.
This also counts for the store, which can get pretty big at times.
If you want to split your store because you know it will be too big, add sub-folders for actions, mutations and so on seperately and then add in the files like 'actions/actions_user.vue' '..actions_items.vue' and so on - or leave out the 'actions_' if you're more comfortable with that (they are in the actions folder now anyway, but it could make it harder to search for them if you're not using the file-tree).
For how to split up actions (and the other content of the store) into multiple files, please look up my answer here
there are also the options to add modules in the store or even adding multiple stores, which contributes to scaleability, but - in my opinion - can get finicky and harder to read than it being useful in the end.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
With Sphinx-doc, you can create a bunch of ReStructureText files, with an index.rst file which includes a table of contents macro that auto generates a table of contents from the other included files, and a conf.py that acts as a compilation config. You can then compile the lot into a single python-doc-style site, complete with index, navigation tools, and a search function.
Is there any comparable tool for markdown (preferably pandoc-style markdown)?
Some static site generators that work with Markdown:
Jekyll is very popular and also the engine behind GitHub pages.
Python variants: Hyde or Pelican
nanoc (used f.ex. in the GitHub API documentation)
Middlemanapp: maybe the best one?
I think none of them use pandoc (maybe because it's written in Haskell), but they all use an enhanced Markdown syntax or can be configured to use pandoc.
Other interesting ways to generate a site from markdown:
Markdown-Wikis that are file based: f.ex. Gollum, the Wiki-Engine that is also used by GitHub
Telegram: commercial; written by David Pollak, the inventor the Lift-Scala-framework
Engines that use Pandoc:
Gitit: Pandoc Wiki
Hakyll: Haskell library to generate static sites
Pandoc-Plugin forIkiwiki
Yst static site generator
Gouda - generates a site from a directory of markdown files
Rippledoc - generates a navigable site from nested directories of markdown files
The definitive listing of Static Site Generators
A good overview of static site generators: http://staticsitegenerators.net/
Pandoc, the GNU make and sed commands, sprinkled with some CSS are all you need to fully automate the creation of a static website starting from Markdown.
Pandoc offers three command line options which can provide navigation between pages as well as the creation of a table of contents (TOC) based on the headings inside the page. With CSS you can make the navigation and TOC look and behave the way you want.
-B FILE, --include-before-body=FILE
Include contents of FILE, verbatim, at the beginning of the document body (e.g. after the tag in HTML, or the \begin{document} command in LaTeX). This can be used to include navigation bars or banners in HTML documents. This option can be used repeatedly to include multiple files. They will be included in the order specified. Implies --standalone.
--toc, --table-of-contents
Include an automatically generated table of contents.
--toc-depth=NUMBER
Specify the number of section levels to include in the table of contents.
The default is 3 (which means that level 1, 2, and 3 headers will be listed in the contents).
As a matter of fact, my personal website is built this way. Check out its makefile for more details. It is all free-libre open-source licensed under the GNU GPL version 3.
If you're OK not using Pandoc, mkdocs would seem to fit your needs.
If you definitely want to use Pandoc-flavoured Markdown, you could check out pdsite. I wrote it as a way to get mkdocs-style site generation with more input formats (like emacs org-mode) and without the Python dependencies - you pass in a folder of Markdown files and get out an HTML site (including automatically-generated multi-level navigation links). It's similar to Serge Stroobandt's approach in that it's just a shell script (it does require you to have tree installed however). Unfortunately it doesn't have a search function yet, although that wouldn't be too hard to add...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have a simple "post" AR class/table. Its based on the "blog tutorial" so it serves the same purpose.
I want to be able to embed images into posts. My design was as follows and I wasn't entirely happy with it so I'll be happy for your feedback:
Design suggestion: Directory protected/data/posts_files/{post_id} would be the repository of posts "resources" (images in our case, but can be anything). Post authors need to put the used images/files in the right location (after the post is created since its id is needed). My needs are really humble so from convenience point of view this is ok. When a post that include such images is requested, CAssetManager will be called to the rescue, to "publish()" the directory of that post (e.g. protected/data/posts_files/17).
In the posts themselves (in their "content" or "body" - which ever term you prefer), images will be embedded with img tags that the src attribute pointing to the published directory for this post_id in the assets folder (for example, after publishing a specific post, WEBROOT/assets/d379e294/some_image.gif).
Problem is that when the post is created/edited, I do not know what path the CAssetManager will create and return - that seemingly random text string (d379e294 in the example above). So, I need on runtime, when loading the 'post', to update its content live, after publishing has been made, with the correct url/paths in the 'src' attribute of the img tags (or for every other kind of resource linked in that 'post').
This was a little challenging: Initially I went with a PHP variable in the 'post' content/body and tried to somehow interpolate it when loading or just before rendering the post. I wasn't successful. I used PHP's eval(), which is very bad practice and dangerous by itself, and it kept crashing complaining on the other content within the 'post' body.
I resorted to have some simple place holder string in the body of the posts - "ASSETS_URL" and str_replace() it when loading the post with the published assets path that I "now" have at hand (at runtime).
I'm not sure this is the best approach. this place holder string could be needed in some post and besides, that seems like a basic templating engine start and my intuition tells me I'm missing something if I do a simple templating engine inside a framework. I just can pin point on the 'right' alternative, the best practice alternative, to do it in Yii.
I wanted to ask for your opinion on this - both on the design of the solution from the higher level and on the design of the implementation itself. Would you change things and make them different?
(I didn't want to dive into KcFinder so intentionally left it out).
Thanks,
Boaz.
Please read the class reference for Yii, it is an amazing tool and is meant to be used.
http://www.yiiframework.com/doc/api/1.1/CAssetManager#publish-detail
If you use the hashByName optional parameter the assetManager will always return the same url if given a folder with the same name as the parameter. However if you try to publish multiple files/folders with the same names with this parameter then it will do nothing assuming that the file/folder already is published, as it hashes by file/folder name rather than the concatenation of parent directory name and modification time.
Then upon the edit of said post just republish with the optional forceCopy to update said files.
As to respond to other's post saying
there's no real justification for using the CAssetManager in this
case
I would like to respond with the fact that obfuscating your directory layout and code is always the best option to avoid being hacked. Especially in a language like php where its limitations are so well known.
Also it allows for you to hide your "uploads" folder so because most of the time it would be with permissions 777 or 755 depending on your web host and setup. This allows you to protect yourself further.
Imho, it seems your entire problem arises because you are using CAssetManager. What advantage does it actually give you?
I would suggest making a directory under your application's root, say : root/post_files/{post_id}/ and storing the post related files there. You can store paths for related post files in the db, and retrieve the file, when needed, using that stored path.
I'm no expert, just my suggestion.