In Weblate, we have a project with several components underneath it. I understand we can disable the addition of new languages in the component settings, but is there a way to restrict languages for a component?
You can use billing module to enforce such limits on projects.
Related
I'm building my first vue.js app and I'd like to have some help on deciding a design approach.
This app is going to be embedded inside a page of a site - built with Drupal 8.
Both app and site are going to use bootstrap 4 as base framework and we're going to use sass to style.
It's a quite simple app: a multistep form with some ajax call done to the aforementioned site.
It has anyway some components - one for each step, for some of the more complex input, for a sidebar showing the result of the ajax calls and so on.
I need to decide the "guideline" for styling this app and I'd like to get some help\insight to what solution is better.
On one hand, I could put the style inside the app itself; on the other hand I could leave all the style to the one present on the site.
As far as I can see the benefits of the first approach are the use of scope of each module, thus having a better "modularity".
However, putting the style all inside the site would avoid code duplication - simple example: custom color variables.
Personally I can't see for now other differences right now.
I haven't found material about the suggested approach and the pros\cons.
Could advice me of which approach is the best? Thank you.
It depends on the project, but you can make a list of cons and pros based on your project brief. If there are very few (or 0) changes in the future or it's based only on small components (not much style) then go with component-scoped styling. If the project is big, always go with a style pattern like the 7-1 pattern
I prefer working with the 7-1 pattern pattern.
Pros:
- Scalability or future updates like you mentioned the color variables case.
- You don't depend on Javascript to load the style, depending on how you write the app or how it loads, it may have glitches.
I develop my own vue components library, and this components have a lot of texts that needs to be localized. vue-i18n doesn't support this, because it should be attached to Vue (e.g. Vue.use(VueI18n)), but in case of component library, it will result in conflict.
I need to have independent translation files in my library, totally separated from my application (to prevent conflicts)
I'm struggling to find any answer to this question in other sources, and I hope someone can give me example for this case. Thanks in advance.
Well it really seems that vue-i18n is not tailored for use in component libraries for reasons you are mentioning (attaching itself into Vue.prototype + conflict with user's code).
I don't know what features of vue-i18n are you using but if it's just simple translation, it seems rolling your own custom solution with an option to plug in the i18n library of user's choice would be the best. It's not that hard. Most of the component libraries are going that way...
You can take a look at how "big guys" do it - in this case Vuetify.
Docs
Code
Need to build an interface. So want to know what is the best and easy way to do it in vue.js
As with a lot of things, there isn't a "best" thing as this is a very subjective matter but we can focus on the "most popular". I will give you an overview of the current state of most popular Vue.js styling solutions:
Vuetify
A complete material design UI framework has a lot of components and is very active, very customizable as well It probably is the most popular UI solution for Vue.js
Quasar Framework
Quasar is also a material based UI framework but it focuses on performance and developer experience, very active and releases often. It also has its own CLI and allows you to target apps using Electron or Cardova, its more of a complete app-bootstrapper than a UI framework.
Bootstrap-Vue
It is like the name suggests, a bootstrap-based UI framework and is the most comprehensive one with full implementation of bootstrap and a lot of custom components as well. It the way to go if you are going with bootstrap-based UIs.
Tailwind CSS
Tailwind is a utility-first CSS framework that uses PostCSS, it is really easy to get started with and very productive, it is my personal favorite because it stays in the CSS and HTML realm, while UI frameworks are very cool and productive, you cannot escape the overhead they introduce and not all designs are based off bootstrap or material anyways. Tailwind manages to stay productive while being very flexible but requires having decent knowledge of CSS and how properties interact.
Again there isn't a "best" framework out there for styling, so you need to study the options and pick the one that "better suits you".
What exactly are the differences between the following (when to use what):
Vue Components
Vue Plugins
Vue Mixins
Components are elements. They are like Blocks of functionality and layout that you would use to build an application or UI. Components can be extended, doing so uses aspects of the original component while giving you the ability to add other functionality.
Similar to extending existing component, you can use a mixin, which is much like a component you'd extend, but it adds functionality to an existing component.
A plugin adds top-level functionality that can be accessed by any component.
The use depends on what you're trying to achieve. Things like routes and state management are a good fit for plugin, because it allows you to affect/listen to changes across the application without setting up props or listeners. But you wouldn't use them for a component-specific functionality, because they would pollute your app.
Mixins is a controversial feature that some argue should not be used. The idea is that Component wrapping or Higher Order Components can implement in a more robust way. more info here:(https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html)
The components are fundamental to building a vue app, so you can't get around using them, but there are ways you can get more out of them. Vue allows use of slots, which help cover some of the functionality, that the react community prefers higher order components does.
If you're relatively new to Vue, I would advise that you don't use mixins, hold off on Plugins until, and spend time with implementing functionality using components and if you're creating re-usable components utilise scoped slots. https://v2.vuejs.org/v2/guide/components-slots.html
At our company we have several React Native components built for iOS. They are all JavaScript based components, so they should work under React Native for Android also. Also, most of the components we have should only differ in the design style, so we need to code those differences between both platforms.
What's the right way to enable this components to support Android? Do we have to use if's checking the app Platform and change the style accordingly? If we want to separate the components in two files, Component.android.js and Component.ios.js, is React Native going to automatically detect which one it needs to use depending on the platform it's running?
There is a very simple solution which I prefer. Just use the file extension: .ios. vs .android.
E.g. look at my nav. I use the android toolbar in the android nav and then I can use navigatorIos for ios if I wish. The application platform will correctly load the corresponding platform file just based on the extension. Which means I just load it normally:
var Nav = require('./jsx/Nav');
I like to follow a declarative approach that React talks about, thus:
1) organizing your files would be by function/behaviour and not by platform as the same file with different extensions will be next to each other.
2) Whether platform to be explicit or implicit isn't relevant as you will only split the file into extensions when it's different platform specific components (so this is inherent)
3) Never any need to handle different platform(s) behaviour in your code ever.
4) This is a composition solution as I've already mentioned: files that are cross-platform do not need the platform extension (and might not need an abstract class for extension in some cases even).
This is a simple solution and I do not know how well it would scale for large projects; but I'm all for the declarative simplicity about it.
1. Organize them
Some components will be IOS-only, some will be Android-only, and some will be cross-platform.
I place my components into 3 directories:
/common/components/
/android/components/
/ios/components/
2. Decide whether you want platform to be explicit or implicit
For every component, there are two basic approaches:
Have the parent manage the platform via composition (i.e. parent selects which component to render and/or passes the platform into the children)
Delegate the platform rendering to the child (i.e. child figures out what platform it's on and renders itself accordingly).
The right approach depends on how different your IOS vs Android layout, style, and functionality are. If the two platforms have different layouts and features, you will likely favor the composition approach. If your code is really isomorphic across platforms then you will likely favor delegation.
3. For trivial differences, use if or switch
If the differences between IOS and Android flavors are purely stylistic (e.g. different style sheet), then you can use a simple if to retrieve the right style.
4. For more significant differences, use inheritance and composition for better modularity
If you have a component which has significant differences between IOS and Android (e.g. <MyCameraWidget>), then you might use a base <BaseCameraWidget> and then have <CameraWidgetIOS> and <CameraWidgetAndroid> variants which extend the base component. This properly separates the cross-platform from the platform-specific logic for better component maintainability later on.
The variants may live in different files, or in the same file, depending on whether you want to expose them or not.
If you are using delegated platform rendering, you will likely want to create a <CameraWidget> facade which has the simple task of figuring out what plaform its on and rendering the correct <CameraWidgetIOS> or <CameraWidgetAndroid> component.
Finally, read this Facebook article on adjustments you may want to make with the React Native packager. There is a blacklist feature which allows you to block out android or IOS files for different builds, but as of today that feature is undocumented and potentially not yet released.