mardi 1 octobre 2019

Extracting configuration from React components

In my React component, I create some input fields based on some configuration object i.e.

[{ label: ‘Client ID’, id: ‘clientId’, placeholder: ‘Enter client ID, e.g. integration-client’, type: ‘text’, stateCallback: setClientId }, { label: ‘Client name’, id: ‘clientName’, placeholder: ‘Enter client name, e.g. Integration Client’, type: ‘text’, stateCallback: setClientName },...]

then, I map this array to jsx

const jsx = array.map(item => toJsx(item))

I wanted to extract the configuration object to different file so my component is not polluted with configuration boilerplate, but the issue is

stateCallback: setClientId

in the configuration object - I pass here references to React Hook's state methods from my component, which will be inaccessible in the new configuration file.

THE QUESTION: Is there a better way / pattern to extract such config from components? Any tips to solve my problem?

Do Web Sockets and Socket.io use Observer Design Pattern?

I'm studying the Observer Design Pattern and I saw the similarities of concepts with Web Sockets, so would the web socket protocol be an implementation of observer pattern? and how about the Socket.io lib ?

Why singleton getInstance method has to be public static in Java

I am just curious why a Singleton class getInstance (or whatever you want to call it) needs to be public static. It only needs to be static not public if that singleton should only be used with in the same package or is my assumption is incorrect.

What are the definitive books or textbooks for understanding Design Patterns?

Background

The Definitive C++ Book Guide and List is a question on stack overflow that gives a comprehensive list of credible C++ textbooks through which to learn C++. I would like to know if there is a definitive list elsewhere, either on a stack exchange or on the internet, that lists credible books on learning Design Patterns. There is one question that deals with this issue from the anti-pattern perspective. However, I do not want information from the anti-pattern perspective. Rather I would like information from the creation of a pattern. Hence my question...

Question

Is there a list of definitive Design Patterns books, like there is for C books and C++ books?

Should DTOs represent nested entity strutctures, or should I have my pathing set up to have an endpoint for each nested object?

For example, lets say I have an entity that looks like this.

public class PersonEntity {
    public String firstName;
    public String lastName;
    public List<CarEntity> cars;
}

Option 1
GET /person/1

{
    "firstName": "Bob",
    "lastName": "Sagget,
    "cars": [
        (could be just IDs or the full Car DTOs)
    ]
}

Option 2
GET /person/1

{
    "firstName": "Bob",
    "lastName": "Sagget"
}

GET /person/1/cars

[
    {
        "make": "Honda",
        "model": "Accord",
        "year": 1992
    },
]

I feel like option 2 is more RESTful. But I also wonder about instances where you will need the full nested set of objects in every scenario. Should I still design it this way in that case?

Fetching and parsing from many sources into one model

I am fetching movie list from many sources, In my app i have single Model lets call it MovieModel that contains var name:String? and var rating:Int?. I fetch from: IMDB, Google, ApiX etc... and each api has its own data structure and key names. at this stage i have a Factory class that have a static func which receives enum as the source and return MovieModel. Design wise, and considering adding more sources at the future what approach would be better? thanks!

Designing an application interface referencing to different APIs under one roof

I want to implement an interface (or Design) with which my application could accept inputs from different resources like Webservices (REST/Soap), File upload, Database and xyz in near future.

My application will accept the input -> Process it with Business logic or Core logic -> Return back in the same format (as it was accepted as request)

Are there better ways to redesign this kind of requirement? and How we could bring all these APIs (Webservice /File / Database) together?